Bajo rendimiento de la consulta

Tenemos un procedimiento grande (más de 10,000 líneas) que generalmente se ejecuta en 0.5-6.0 segundos dependiendo de la cantidad de datos con los que tiene que trabajar. Durante el último mes, más o menos, ha comenzado a tomar más de 30 segundos después de realizar una actualización de estadísticas con FULLSCAN. Cuando se ralentiza, un sp_recompile "soluciona" el problema, hasta que el trabajo de estadísticas nocturnas se ejecuta nuevamente.

Al comparar los planes de ejecución lenta y rápida, lo he reducido a una tabla / índice específico. Cuando se ejecuta lentamente, se estima que se devolverán ~ 300 filas de un índice específico, cuando se ejecuta rápidamente se estima 1 fila. Cuando se ejecuta lentamente, usa un Table Spool después de hacer una búsqueda en el índice, cuando se ejecuta rápido no hace el Table Spool.

Usando DBSS SHOW_STATISTICS, graficé el histograma de índice en Excel. Normalmente esperaría que el gráfico sea más "colinas onduladas", pero en cambio, parece una montaña, el punto más alto es 2x-3x más alto que la mayoría de los otros valores en el gráfico.

Si actualizo las estadísticas, sin FULLSCAN, parece más normal. Si luego lo ejecuto con FULLSCAN nuevamente, parece que lo describí anteriormente.

Esto se siente como un problema de análisis de parámetros, y específicamente relacionado con la distribución de índices (aparentemente) extraña anterior.

El proceso toma un parámetro con valores de tabla, ¿puede suceder el rastreo de parámetros en un parámetro con valores de tabla?

EDITAR: El proceso también toma otros 12 parámetros, algunos de los cuales son opcionales, dos de los cuales son una fecha de inicio y finalización.

¿El histograma es extraño o estoy ladrando al árbol equivocado?

Ciertamente me siento cómodo tratando de ajustar la consulta y / o tratar de ajustar mi indexación. Si esa es la solución que es genial, en ese momento mi pregunta es más sobre el histograma sesgado.

Debo mencionar que este es un índice agrupado de IDENTIDAD PK. Tenemos dos sistemas que se comunican entre sí, uno es un sistema heredado y otro un nuevo sistema interno. Ambos sistemas almacenan datos similares. Para mantenerlos sincronizados, el PK en esta tabla en el nuevo sistema se incrementa cuando se agregan elementos al sistema anterior, incluso si los datos no se transfieren (se realiza una RESEED). Por lo tanto, podría haber algunas lagunas en la numeración en esta columna. Los registros rara vez, si es que se eliminan

Cualquier pensamiento sería muy apreciado. Estoy más que feliz de reunir / incluir más información.

Esto terminó estando relacionado con la detección de parámetros. Dio la casualidad de que algunas versiones extrañas de esta consulta se estaban ejecutando MISMO DESPUÉS de que se reconstruyeron las estadísticas. Por lo tanto, el plan en caché no era representativo de la mayoría de las llamadas. Utilicé el truco de copiar los parámetros de fecha en variables locales y esto funciona bien, con poco o ningún impacto en el rendimiento. Esto no responde por qué el histograma se ve tan "apagado", pero explica mis problemas de rendimiento.