Uso de tablas temporales en SQL Server

Question

Esta es una pregunta un poco abierta, pero realmente me gustaría escuchar las opiniones de las personas.

Raramente hago uso de tablas temporales explícitamente declaradas (ya sean variables de tabla o tablas #tmp regulares) ya que creo que no hacerlo conduce a T-SQL más conciso, legible y depurable. También creo que SQL puede hacer un mejor trabajo que el de hacer uso de almacenamiento temporal cuando es necesario (como cuando se utiliza una tabla derivada en una consulta).

La única excepción es cuando la base de datos no es una base de datos relacional típica sino un esquema de estrella o copo de nieve. Entiendo que es mejor aplicar filtros primero a la tabla de hechos y luego usar la tabla temporal resultante para obtener los valores de sus dimensiones.

¿Es esta la opinión común o alguien tiene una opinión contraria?

Answer 1

Las tablas temporales son más útiles para un proceso por lotes complejo como un informe o un trabajo ETL. En general, esperaría usarlos con bastante poca frecuencia en una aplicación transaccional.

Si realiza una consulta compleja con una combinación que implica varias tablas grandes (tal vez para un informe), el optimizador de consultas no puede optimizar esto en un hit, por lo que las tablas temporales se convierten en una ganancia. Descomponen consulta en una serie de más simples que le dan al optimizador de consultas menos oportunidades de arruinar el plan. En ocasiones, tiene una operación que no se puede realizar en una sola declaración SQL, por lo que son necesarios varios pasos para procesarla. Una vez más, estamos hablando de manipulaciones más complejas aquí.

También puede crear una tabla temporal para un resultado intermedio y luego indexar la tabla, posiblemente incluso colocando un índice agrupado en ella para optimizar una consulta posterior. Esta también puede ser una manera rápida y sucia de optimizar una consulta de informe en un sistema donde no se le permite agregar índices al esquema de la base de datos. SELECT INTO es útil para este tipo de operación ya que está mínimamente registrado (y por lo tanto rápido) y no requiere alinear las columnas de una selección e inserción.

Otras razones pueden incluir la extracción de datos de campos XML utilizando las solicitudes CROSS APPLY y xpath. En general, es mucho más eficiente extraer esto en una tabla temporal y luego trabajar en la tabla temporal. También son mucho más rápidos que los CTE para algunas tareas, ya que materializan los resultados de la consulta en lugar de volver a evaluar la consulta.

Una cosa a tener en cuenta es que las tablas temporales son exactamente la misma estructura que usa el motor de consulta para almacenar los resultados de las uniones intermedias, por lo que no hay una penalización de rendimiento al usarlas. Las tablas temporales también permiten tareas de varias fases usando operaciones de conjunto y hacen que los cursores sean casi (no del todo, pero casi) innecesarios en el código T-SQL.

'Code Smell' es una exageración, pero si veo muchas operaciones simples que involucran tablas temporales, me pregunto qué está pasando.

Answer 2

Veo las tablas temporales como una especie de olor a código SQL, para ser utilizado solo como último recurso. Si tiene que almacenar en caché los datos antes de obtener un conjunto de resultados final, generalmente me indica un diseño de base de datos malo.

Answer 3

Realmente depende de lo que está haciendo. Generalmente trato de evitarlos, pero a veces necesitas hacer algo complicado que requiere varios pasos. En general, esto es mucho más allá de la simple selección de cosas de la mesa. Como cualquier otra cosa, es una herramienta que debes saber cuándo usar.

Estoy de acuerdo con usted en que normalmente dejo que el DB maneje cosas detrás de escena, pero hay momentos en que la optimización está desactivada y tiene que entrar y hacerlo a mano.

Answer 4

Yo también evito las tablas temporales. Entiendo que las tablas temporales en MS SQL Server siempre están en el grupo de archivos de la base de datos maestra. Lo que eso significa es que, aunque las tablas de aplicaciones de producción probablemente se encuentren en algún sistema RAID costoso y de alto rendimiento, las tablas temporales se ubican donde se instaló MS SQL Server, lo más probable es en su unidad C: en el directorio Archivos de programa.

Answer 5

Las tablas de temperatura ciertamente tienen usos apropiados, no son un olor a código si se usan correctamente. Una de las cosas buenas de ellos es que viven en tempdb, que generalmente se establece en el modelo de recuperación simple. Esto significa que si está utilizando tablas temporales para lo que son buenas (principalmente operaciones masivas), está generando una cantidad mínima de logs en comparación con lo que haría la misma operación en tablas en su producción db, que probablemente sea en el modelo de recuperación completa.

Si, como sugirió otro afiche, su producción db tiene un buen hardware, pero su tempdb no lo está, solicite a su DBA que lo mueva. El propio SQL Server usa bastante tempdb para procesar sus consultas, por lo que es importante que tempdb tenga un hogar de alto rendimiento.

Las variables de tabla son completamente diferentes. Ellos viven solo en la memoria. Un buen uso para ellos es si tienes una función que necesitas llamar para cada fila en tu consulta con CROSS APPLY. Si esa función es costosa, pero la cantidad de resultados diferentes que puede obtener es pequeña, puede obtener un rendimiento significativamente mayor al precomputar los resultados de todas las llamadas posibles (o quizás todas las llamadas posibles para su conjunto de datos) y almacenar eso en una variable de tabla, luego unirse a esa variable de tabla en lugar de usar CROSS APPLY.

Answer 6

También es útil cuando tiene un conjunto de datos que debe recuperarse una vez y utilizarse una y otra vez en declaraciones posteriores.

Hace que estos largos procesos por lotes sean más legibles (a veces esto es más importante que el rendimiento).