tsql - indice - tablas temporales vs variables tipo tabla sql server

Mejor uso de índices en tablas temporales en T-SQL

Question

Si está creando una tabla temporal dentro de un procedimiento almacenado y desea agregar un índice o dos en ella, para mejorar el rendimiento de las declaraciones adicionales formuladas en su contra, ¿cuál es el mejor enfoque? Sybase dice esto :

"la tabla debe contener datos cuando se crea el índice. Si crea la tabla temporal y crea el índice en una tabla vacía, Adaptive Server no crea estadísticas de columna como histogramas y densidades. Si inserta filas de datos después de crear el índice, el optimizador tiene estadísticas incompletas ".

pero recientemente un colega mencionó que si creo la tabla temporal y los índices en un procedimiento almacenado diferente al que realmente usa la tabla temporal, el optimizador de Adaptive Server podrá hacer uso de ellos.

En general, no soy un gran admirador de los procedimientos de envoltura que agregan poco valor, así que no he podido evaluar esto, pero pensé que podría plantear la pregunta, para ver si alguien tenía alguna otra enfoques o consejos?

Answer 1

¿Cuál es el problema al agregar los índices después de poner datos en la tabla temporal?

Una cosa que debe tener en cuenta es la visibilidad del índice para otras instancias del procedimiento que podrían estar ejecutándose al mismo tiempo.

Me gusta agregar un guid a este tipo de tablas temporales (y a los índices), para asegurarme de que nunca haya un conflicto. El otro beneficio de este enfoque es que simplemente puede hacer que la tabla temporal sea una tabla real.

Además, asegúrese de que deberá consultar los datos en estas tablas temporales más de una vez durante la ejecución del procedimiento almacenado; de lo contrario, el costo de la creación del índice superará el beneficio para la selección.

Answer 2

En Sybase, si creas una tabla temporal y luego la usas en un proceso, el plan para la selección se genera utilizando una estimación de 100 filas en la tabla. (El plan se genera cuando el procedimiento se inicia antes de que se llenen las tablas). Esto puede dar como resultado que la tabla temporal sea escaneada, ya que solo se trata de "100 filas". Llamar a otro proceso hace que Sybase cree el plan para la selección con el número real de filas, esto permite que el optimizador elija un mejor índice para usar. He visto mejoras significativas usando este enfoque, pero la prueba en su base de datos ya que a veces no hay diferencia.

Answer 3

Algunas reflexiones

• Si su tabla temporal es tan grande que debe indexarla, ¿existe una forma mejor de resolver el problema?

• Puede obligarlo a usar el índice (si está seguro de que el índice es la forma correcta de acceder a la tabla) dando una sugerencia de optimización del formulario:

  SELECT *
  FROM #table (index idIndex)
  WHERE id = @id

Si está interesado en consejos de rendimiento en general, he respondido algunas otras preguntas al respecto aquí:

• Trucos de ajuste de rendimiento favoritos
• ¿Cómo se optimizan las tablas para consultas específicas?