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

Question

Si está creando una tabla temporal dentro de un procedimiento almacenado y desea agregarle uno o dos índices para mejorar el rendimiento de cualquier declaración adicional realizada en su contra, ¿cuál es el mejor enfoque?Sybase dice este:

"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 columnas 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, entonces el optimizador de Adaptive Server voluntad poder hacer uso de ellos.

En general, no soy un gran admirador de los procedimientos envolventes que agregan poco valor, por lo que en realidad no he podido probar esto, pero pensé en plantear la pregunta para ver si alguien tenía alguna otra. enfoques o consejos?

Answer 1

Algunas reflexiones:

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

• Puede forzarlo a usar el índice (si está seguro de que el índice es la forma correcta de acceder a la tabla) dándole una sugerencia de optimización, de la forma:

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

Si está interesado en consejos de rendimiento en general, he respondido un par de preguntas más al respecto aquí con cierta extensión:

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

Answer 2

¿Cuál es el problema con agregar índices después de colocar 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 una guía 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 se puede convertir la tabla temporal en una tabla real.

Además, asegúrese de que necesitará consultar los datos en estas tablas temporales. mas 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 el seleccionado.

Answer 3

En Sybase, si crea una tabla temporal y luego la usa en un proceso, el plan para la selección se construye usando una estimación de 100 filas en la tabla.(El plan se construye cuando el procedimiento comienza antes de que se completen las tablas). Esto puede dar como resultado que la tabla temporal se escanee, ya que solo tiene "100 filas".Llamar a otro proceso hace que Sybase cree el plan para la selección con el número real de filas, lo que permite al optimizador elegir un mejor índice para usar.He visto mejoras significativas al utilizar este enfoque, pero pruébelo en su base de datos ya que a veces no hay diferencia.