SQL Server: ¿Son mejores las tablas temporales o las uniones?

Question

En general, para combinar una gran cantidad de datos, ¿es mejor usar una tabla temporal/variable de temperatura como área de preparación o debería simplemente adherirme a "UNION ALL"?

Supuestos:

• No se necesita ningún tratamiento posterior, los resultados se envían directamente al cliente.
• El cliente espera el conjunto de registros completo, por lo que los resultados de la transmisión no son necesarios.

Answer 1

Me quedaría con UNION ALL. Si no hay necesidad de hacer un procesamiento intermedio, por lo tanto, requiere una tabla temporal, entonces no usaría uno.

Insertar datos en una tabla temporal (incluso si es una variable de tabla que a pesar de los mitos, no es una estructura puramente "en memoria") implicará trabajo en tempdb (que puede ser un cuello de botella). Entonces, simplemente SELECCIONAR * tal como está y devolverlo sin ningún procesamiento especial es innecesario y creo que aumenta el código. Cuando solo necesita devolver datos sin ningún procesamiento especial, entonces un enfoque de tabla temporal parece un poco "alrededor de las casas". Si creía que había una razón para justificar el uso de una tabla temporal, ejecutaba algunas pruebas de rendimiento para comparar con vs sin tablas temporales, luego comparaba las estadísticas (duración, lecturas, escrituras, CPU). Hacer las pruebas de rendimiento reales es la mejor manera de tener la mayor confianza posible, independientemente de cuál sea el enfoque que elija, es el mejor. Especialmente porque no tiene que estar usando tablas temporales para que el trabajo se transfiera a tempdb, es decir, dependiendo de sus consultas, podría implicar trabajar en tempdb de todos modos.

Para aclarar, no estoy diciendo que uno sea mejor que el otro punto. Como con la mayoría de las cosas, depende del escenario. En el escenario descrito, suena como si estuvieras agregando un paso adicional que no parece agregar ningún valor funcional y no veo que obtengas nada más que crear una consulta un poco más complicada/larga.

Answer 2

Una ventaja con las tablas temporales que puedo pensar es que puede aplicar índices a ellas. De modo que eso debería ser útil cuando se trata de una gran cantidad de datos en los que debe obtener los resultados lo más rápido posible.

Answer 3

no específica a la unión de todo ..

El uso de tabla temporal podría tener una ventaja desde el POV de concurrencia en función de consulta, nivel de aislamiento y rendimiento de los clientes/enlace de red donde el uso de una tabla temporal podría servir para reducir al mínimo lee los tiempos de bloqueo. Simplemente no use SELECT ..INTO .. ​​para crear la tabla.

En el caso general UNION ALL evita la sobrecarga de una mesa de trabajo innecesaria.

Answer 4

Tiendo a usar solamente UNION ALL donde tengo un número limitado de SINDICATOS - y un número relativamente limitado de columnas devueltas, las variables de tabla son otra posibilidad (especialmente para el 2014 en adelante) - y le permiten aplicar uniformidad de estructura si se generan conjuntos de resultados similares en más de una ubicación.

UNION ALL evita pasos intermedios sino: 1) puede conducir a la hinchada, difícil de mantener el código 2) que puede conducir a los planes de consulta inmanejables - si se acercan demasiado grande, entonces las herramientas de visualización del plan en SQL Server pueden' en realidad los ve 3) si partes de una unión compleja son similares, o pueden usarse en cualquier otro lugar de su sistema, considere usar funciones con valores de tabla o procesos almacenados para facillitar la reutilización de código ya sea que elija TTV, UNION ALL o Temp Tables

Answer 5

Por lo que vale, acabo de hacer una comparación de rendimiento entre dos enfoques para recuperar conjuntos de datos idénticos:

SELECT c1, c2, c3 FROM ... ON ... WHERE 
UNION ALL 
SELECT c1, c2, c3 FROM ... ON ... WHERE /*(repeated 8 times)*/ 

vs

CREATE TABLE #Temp (c1 int, c2 varchar(20), c3 bit) 
INSERT INTO #Temp (c1, c2, c3) SELECT (c1,c2,c3) FROM ... WHERE... /*(repeat 8 times)*/ 
SELECT c1, c2, c3 FROM #Temp 

El segundo enfoque (la tabla temporal) fue de aproximadamente 5% más lento que el sindicato, y cuando escalé artificialmente el número de repeticiones, el segundo enfoque se hizo aún más lento.