Creando una tabla usando una declaración explícita de crear tabla versus seleccionar en

Question

¿Hay alguna diferencia en el rendimiento entre usar una declaración explícita de tabla de creación y cargar datos versus seleccionar en. Este ejemplo solo muestra 2 columnas, pero la pregunta está orientada hacia el uso de tablas muy grandes. El ejemplo a continuación también usa tablas temporales, aunque me pregunto los efectos sobre el uso de tablas regulares también. Creo que serían los mismos independientemente del tipo de mesa. tabla

Temperatura escenario:

--- Explicitly creating temp table first and then loading. 
create table #test1 (id int, name varchar(100)) 
insert into #test1 (id, name) select id, name from #bigTable 

--- Creating temp table by selecting into. 
select id,name into #test2 from #bigTable 

o mesas regulares:

--- Explicitly creating table first and then loading. 
create table test1 (id int, name varchar(100)) 
insert into test1 (id, name) select id, name from #bigTable 

--- Creating table by selecting into. 
select id,name into test2 from bigTable 

¿Cuáles son los pensamientos de todos en esto? Creo que la creación explícita de la tabla y la carga deben tener un mejor rendimiento que seleccionar en como seleccionar en debe evaluar las expresiones dentro de la declaración para crear una tabla.

Nuestra organización generalmente crea tablas temporales explícitamente como una práctica estándar, y nos preguntamos qué es lo que todo piensa es en realidad la mejor práctica.

http://msdn.microsoft.com/en-us/library/ms188029.aspx

Answer 1

CREATE TABLE le da un mejor control sobre la definición de su tabla antes de insertar los datos, como NOT NULL, restricciones, etc. cosas que no puede hacer usando SELECT INTO.

SELECT INTO es una operación mínimamente registrada, pero INSERT..SELECT también se puede registrar mínimamente, en algunas condiciones.
Consulte The Data Loading Performance Guide, especialmente la sección: Resumen de condiciones mínimas de registro.

En pocas palabras, si no le importan las limitaciones, etc. (por ejemplo, si desea crear rápidamente una copia de una tabla), la ventaja de SELECT..INTO en mi humilde opinión es un código más corto.
De lo contrario, debería usarlo de otra manera, y aún así podría tenerlo registrado mínimamente.

Answer 2

Seleccione en el registro ha beneficios (no hace tanto), por lo que el rendimiento es realmente mejor en la mayoría de los casos. Sin embargo, se produce un error si la tabla existe y no genera elementos como índices o restricciones, solo columnas.

Depende de lo que lo necesite. Sé que tenemos algunas acciones que SELECT ... INTO cambian de nombre porque es más rápido que actualizar la tabla anterior (obviamente con mucha actividad para reconstruir objetos de tabla, etc.).

Tenga en cuenta que nuestro uso no es con tablas temporales, lo que acabo de notar en su pregunta es el caso.

En el caso de tablas con índices, insert into tendrá que mantener los índices como parte del proceso de inserción. Hay otros objetos de tabla que pueden causar más procesamiento, como desencadenantes. En el caso de seleccionar, la tabla es escueta, por lo que yo sé, por lo que el rendimiento inicial de inserción es excelente. Además, el impacto del registro de transacciones es mínimo (se menciona esto en ese enlace en su pregunta).

Realmente depende del uso, para las tablas temporales, supongo que van a ser de vida relativamente corta, por lo que seleccionar en seguido de un truncado/caída puede funcionar bien. Si tienen tramos más largos, pero de lo contrario se tiran, seleccione de nuevo en seguido de una caída eventual que puede funcionar.

Si necesitan vivir mucho después de haber sido creados y no son desechables, entonces, aparte de la creación inicial y la inserción de datos (que serán rápidos), volverán a ser cuadrados en términos de inserciones posteriores: lo mejor sería que simplemente ajuste la tabla para aceptar inserciones rápidas, por ejemplo, teniendo índices mínimos o deshabilitando los índices antes y volviendo a habilitar la inserción de publicaciones.

En el caso de las tablas grandes que tienen índices agrupados, también he visto un truco en el que los datos que se insertan están ordenados por el índice agrupado en la inserción.

Answer 3

En mi caso, hacer un CREATE explícito y luego INSERTAR INTO realizó notablemente mejor en el tiempo de ejecución real y el costo estimado por el optimizador.

Mi tabla temporal no era grande (8 filas), pero uno de los valores era un valor de cadena calculado. En algunos casos, esta tabla temporal se unió con un conjunto de resultados con cientos de miles de filas. Creo que cuando hice un SELECT INTO para mi tabla temporal, no optó de manera óptima por un tipo de datos para el valor calculado. Entonces, cuando definí explícitamente los tipos de datos de columna usando CREATE, SQL Server pudo realizar la unión de manera más eficiente. Por supuesto, este efecto fue exagerado porque se involucraron tantas filas.

Por lo tanto, parece que en algunos casos, especialmente cuando una de sus columnas es un valor calculado, CREAR e INSERTAR puede ser la mejor opción. Su kilometraje puede variar, por supuesto, así que asegúrese de realizar algunas pruebas.