Consulta tuning 101
No hay una bala mágica de plata para el ajuste de consultas, aunque puedo darle algunos consejos y sugerencias. Lo primero que debe hacer es comprender lo que realmente sucede detrás de escena. Obtenga un buen libro interno como el tercer libro de la Guía del Gurú.
Las consultas con un rendimiento deficiente tienden a presentarse en dos tipos básicos: consultas transaccionales que demoran demasiado y trabajos de procesamiento por lotes (o informes) que demoran demasiado. Una buena señal de una consulta con algo incorrecto es que un solo elemento en el plan de consulta toma el 99% del tiempo.
Consultas transaccionales
En la mayoría de las ocasiones, una consulta transaccional de bajo rendimiento es una de las pocas cosas:
Un índice faltante. Puede ver esto en el plan de consulta: escaneos de tablas de tablas grandes en una unión que deberían ser muy selectivas (es decir, devolver algunas filas).
La consulta no puede usar un índice. Si tiene condiciones OR en la cláusula where, se une a un valor calculado u otro elemento en la consulta que no es sargible, entonces es posible que deba volver a escribir la consulta. En resumen, los sargs son predicados de consulta que pueden usar índices para eliminar filas. Y lógico, la igualdad y la desigualdad (>,> =, <, <= y! =) Son todas sargibles. O tradicionalmente no es sargible. Sin embargo, a menudo puede traducir OR en predicados sargibles invirtiendo el sentido de construcciones de tipo OR a NOT (foo y no bar).
Predicados ineficientes. Por ejemplo, si hace where inreferencia a una subconsulta anidada, vea si puede reescribirse como where existso como una combinación. Esto puede resultar en planes de consulta más eficientes y aquí hay otras reescrituras estándar que puede probar también. Una vez más, las guías del Gurú y otros sobre el tema son un buen punto de partida.
Consultas por lotes
Las consultas por lotes son más complicadas y tienen diferentes problemas de ajuste. Algunos consejos son:
Indexación. Esto puede marcar una gran diferencia por la misma razón que lo hace con las consultas transaccionales. A menudo, una buena señal de que falta un índice es una operación de rectificado larga (99% del plan de consulta) que no parece estar agitando la máquina.
Tablas temporales. Puede que le resulte mejor dividir una consulta en varias consultas que llenen tablas temporales. Las consultas más grandes le dan al optimizador más espacio para fastidiar, aunque esto ya no es un problema que solía ser. Cree las tablas temporales select intoya que esta operación se registra mínimamente (mucho menos actividad de registro), lo que reduce la carga de E / S.
Tenga en cuenta que las tablas temporales en tempdb son la misma estructura de datos que utiliza el optimizador para almacenar resultados de unión intermedios, por lo que no hay penalización de rendimiento por hacer esto. También puede crear un índice (incluidos los índices agrupados y de cobertura) en una tabla temporal, lo que puede mejorar el rendimiento de las consultas que lo leen por las mismas razones por las que mejoran las consultas en tablas estáticas.
Sin embargo, no exagere las tablas temporales, ya que pueden hacer que las cosas sean más difíciles de rastrear a través de la consulta. Para tablas más pequeñas dentro de un procedimiento almacenado, pruebe para ver si las variables de tabla ayudan. Se trata de una estructura de datos en memoria, por lo que pueden ser una ganancia de rendimiento.
Índices agrupados y de cobertura. Estos pueden mejorar el rendimiento de una consulta ya que fuerzan la localidad de referencia en el disco en función de alguna columna de agrupación. Un índice agrupado puede marcar una gran diferencia en el rendimiento de un trabajo por lotes.
Predicados ineficientes. Esto puede causar problemas con sargs y otras emisiones de suboptimización de la misma manera que lo hacen con las consultas transaccionales.
El escaneo de mesa es tu amigo. Contrariamente a la creencia popular, los escaneos de mesa no son intrínsecamente malos. En general, son un signo de que algo anda mal en una consulta transaccional, pero a menudo son la forma más eficiente de realizar una operación por lotes de gran tamaño. Si está haciendo algo con más de un pequeño porcentaje de filas en una tabla, un escaneo de tabla suele ser la forma más eficiente de cubrir la tabla.
Bucles anidados se une. Eche un vistazo a lo que está haciendo el optimizador en ambos lados de la unión. Esto puede ser ineficiente si lo es (por ejemplo, una tabla que explora dos tablas grandes a ambos lados de una unión de bucles anidados. Considere usar índices agrupados o order bye intente cambiar la operación a una combinación de fusión o sugerencia para promover una combinación hash si un lado está lo suficientemente pequeño como para hacer esto.
Cierre
El bloqueo también puede causar problemas de rendimiento. Si su sistema está funcionando mal bajo carga, mire el perfilador y los contadores de rendimiento relacionados con los bloqueos y verifique si hay alguna disputa significativa. sp_who2tiene una columna 'BlkBy' en el conjunto de resultados que mostrará si una consulta está bloqueada y qué la está bloqueando. Además, los perfiles con eventos de 'gráfico de punto muerto' (si tiene consultas de punto muerto) y eventos relacionados con el bloqueo pueden ser útiles para solucionar problemas de bloqueo.