viernes, 9 de mayo de 2014

Formato de la orden INSERT- SELECT

Sintaxis general de INSERT ... SELECT

INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
    [INTO] tbl_name [(col_name,...)]
    SELECT ...
    [ ON DUPLICATE KEY UPDATE col_name=expr, ... ]


Co esta orden se puede insertar rapidamente  varias columnas en una tabla con datos de otra tabla o de otras tablas.
Un ejemplo:

INSERT INTO tbl_temp2 (fld_id)
  SELECT tbl_temp1.fld_order_id
  FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
Las siguientes indicaciones siguen como esta en el articulo original, ya que son extra:
The following conditions hold for a INSERT ... SELECT statements:

  -  Specify IGNORE to ignore rows that would cause duplicate-key violations.

 -   DELAYED is ignored with INSERT ... SELECT.

  -  AUTO_INCREMENT columns work as usual.

  -  To avoid ambiguous column reference problems when the SELECT and the INSERT refer to the same table, provide a unique alias for each table used in the SELECT part, and qualify column names in that part with the appropriate alias.

In the values part of ON DUPLICATE KEY UPDATE, you can refer to columns in other tables, as long as you do not use GROUP BY in the SELECT part. One side effect is that you must qualify nonunique column names in the values part.

The order in which rows are returned by a SELECT statement with no ORDER BY clause is not determined. This means that, when using replication, there is no guarantee that such a SELECT returns rows in the same order on the master and the slave; this can lead to inconsistencies between them. To prevent this from occurring, you should always write INSERT ... SELECT statements that are to be replicated as INSERT ... SELECT ... ORDER BY column. The choice of column does not matter as long as the same order for returning the rows is enforced on both the master and the slave.

In case of used MySQL, the statement INSERT ... SELECT that acts on partitioned tables using a storage engine such as MyISAM that employs table-level locks locks all partitions of the source and target tables. This does not occur with tables using storage engines such as InnoDB that employ row-level locking. This issue is resolved in MySQL 5.6. 

Fuente:  http://docs.oracle.com/cd/E17952_01/refman-5.1-en/insert-select.html



No hay comentarios:

Publicar un comentario