Diferencias entre SELECT INTO e INSERT INTO

SELECT INTO e INSERT INTO son dos operaciones muy diferenciadas, al menos en el caso de SQL Server. Ambas son instrucciones de Transact-SQL que se ejecutan dentro de SQL Server (in-process). Recordar, que existen utilidades como BCP.EXE que se ejecutan fuera de la instancia de SQL Server (out-of-process), de hecho, son ejecutables independientes... como ocurre con utilidades similares en otros motores de base de datos como DB2, Informix, ORACLE, etc. A continuación se describen las características de ambas instrucciones:

• SELECT INTO. Se trata de una Operación de Registro Mínimo, y dentro de este tipo de operaciones se trata de una operación de copia masiva (Bulk Copy ó BULK). Su ejecución escribirá en el LOG de SQL Server el mínimo de información necesaria, dependiendo del modo de recuperación (recovery) que tenga configurada la base de datos de destino, consiguiendo así mejorar el rendimiento sensiblemente.
  
  La tabla destino no debe existir, debido a que será creada al vuelo durante la ejecución de la sentencia SELECT INTO. Esto tiene varias implicaciones de importancia. Por un lado, no es posible utilizar SELECT INTO para agregar filas a una tabla existente, algo necesario en muchas ocasiones, y que resultaría beneficioso poder realizar a través de operaciones de registro mínimo (mejorando el rendimiento al minimizar las escrituras en LOG). Por otro lado, el tipo de datos, precisión y resto de características (ej: admitir valores NULL) de los campos de la tabla destino, serán inferidos de la consulta origen, teniendo en cuenta además, que no tenemos posibilidad de definir o inferir todas las características del origen (ej: la definición de índices, autonuméricos o IDENTITY, etc). El caso particular de los campos autonuméricos o IDENTITY podemos cubrirlo en cierta medida con las funciones de RANKING de SQL Server.
  
  En consecuencia, en ocasiones la tabla destino de un SELECT INTO, tiene campos con tipos de datos, precisiones u otras características, que no imaginábamos en un principio, que nos perjudica para nuestro propósito, y que nos puede costar controlar. Esto suele ocurrir cuando hacemos el INTO de una SELECT compleja, con cláusulas JOIN (ej: LEFT JOIN), realizando concatenaciones de campos, aplicando funciones a los campos seleccionados, haciendo conversiones de tipos (CASTING) explícitos e implícitos, etc.
  
  La tabla destino de un SELECT INTO no contendrá ningún índice, ni índices agrupados (clustered index) ni índices no agrupados (non-clustered index). Evidentemente, puesto que la tabla no puede existir, y durante la creación implícita de la tabla al ejecutar SELECT INTO se creará sin índices, por lo que será una simple estructura algorítmica de Montón (Heap).
  
  Es importante recordar que si intentamos ejecutar una sentencia SELECT INTO y la tabla de destino existe, obtendremos el siguiente error (evidente, ya que no debe existir la tabla destino previamente):
  
  Mens. 2714, Nivel 16, Estado 6, Línea 1
  Ya hay un objeto con el nombre ' DIM_Usuarios ' en la base de datos.
  
  Mens. 2714, Nivel 16, Estado 6, Línea 1
  There is already an object named ' DIM_Usuarios ' in the database.
  
  A continuación, se muestra un ejemplo de SELECT INTO.

• INSERT INTO. Al contrario que SELECT INTO, INSERT INTO no es una Operación de Registro Mínimo, por lo cual, su ejecución realizará un registro completo en el LOG de SQL Server, independientemente del Modo de Recuperación utilizado.
  
  A diferencia que ocurre con SELECT INTO, INSERT INTO requiere que la tabla de destino ya exista, para poder ejecutarse (si no existe, deberemos crear la tabla previamente con un CREATE TABLE, o con un SELECT INTO con una condición falsa como WHERE 1=0).
  
  Las ventajas de tener creada la tabla destino previamente, es el hecho de que el esquema de la tabla destino lo tendremos controlado perfectamente (ej: tipos de datos, precisión, admisión de valores NULL, intercalación, utilización de campos autonuméricos para la creación de Claves Subrogadas, etc.). Evidentemente, al realizar una inserción fruto de una selección de múltiples filas, estamos expuestos a diferentes tipos de violaciones del esquema de destino, como pueda ser violación de clave primaria o de índices únicos, violación de restricciones NOT NULL, etc. Pero quizás la principal ventaja de INSERT INTO como consecuencia de que la tabla destino deba existir, es que con INSERT INTO podemos agregar filas a una tabla existente que ya contiene filas, mientras que con SELECT INTO siempre crearemos una nueva tabla vacía sobre la que insertaremos.
  
  La existencia de índices en la tabla destino puede perjudicar el rendimiento, por lo que se puede estudiar la posibilidad de eliminar índices antes de cargar, para cargar, y seguidamente crear de nuevo los índices.
  
  Volviendo al caso de uso de un Data Warehouse, es muy habitual el desarrollo de cargas incrementales de las tablas de hechos y tablas de dimensión. Por ejemplo, podemos tener un Data Mart que se carga con periodicidad mensual, y cada mes agregamos las nuevas filas de hechos y de dimensiones, para lo cual parece evidente que utilizaremos sentencias INSERT INTO (agregando así las nuevas filas a las tablas existentes), aunque en ocasiones utilicemos una tabla temporal (quizás con un SELECT INTO) con ciertas transformaciones básicas, como paso previo al INSERT INTO sobre la tabla definitiva (INSERT INTO que leerá de la tabla temporal creada previamente con SELECT INTO).
  
  A continuación se muestra un ejemplo de INSERT INTO.