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 cualquier declaración adicional realizada en su contra, ¿qué es el mejor enfoque? dice Sybase this:

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

pero recientemente un colega mencionado que si puedo crear la tabla temporal y los índices en un procedimiento almacenado diferente a la que en realidad se utiliza la tabla temporal, entonces adaptativa optimizador servidor será capaz de hacer uso de ellos.

En general, no soy un gran admirador de los procedimientos de envoltura que agregan poco valor, así que no he llegado a probar esto, pero pensé en plantear la pregunta, para ver si Alguien tenía otros enfoques o consejos?

Answer 1

algunas ideas:

• Si su tabla temporal es tan grande que usted tiene para indexarlo, entonces hay una mejor manera de resolver el problema?

• Puede forzar que se use el índice (si está seguro de que el índice es la forma correcta de acceder a la tabla), dando un toque optimizador, de la forma:

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

Si usted está interesado en consejos de rendimiento en general, me ha contestado a un par de preguntas acerca de que en algún detalle aquí:

• Favourite performance tuning tricks
• How do you optimize tables for specific queries?

Answer 2

¿Cuál es el problema al agregar los índices después de poner los 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 garantizar 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 creación del índice superará el beneficio para la selección.

Answer 3

En Sybase, si crea una tabla temporal y luego la usa 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.