Mauvaise performance des requêtes

Nous avons une grande procédure (10 000+ lignes) qui s'exécute généralement en 0,5 à 6,0 secondes selon la quantité de données avec laquelle elle doit travailler. Au cours du mois dernier, il a commencé à prendre plus de 30 secondes après une mise à jour des statistiques avec FULLSCAN. Lorsqu'il ralentit, un sp_recompile "résout" le problème, jusqu'à ce que le travail de statistiques nocturnes s'exécute à nouveau.

En comparant les plans d'exécution lente et rapide, je l'ai réduit à une table / un index spécifique. Lorsqu'il s'exécute lentement, il estime que ~ 300 lignes seront renvoyées à partir d'un index spécifique, lorsqu'il s'exécute rapidement, il estime 1 ligne. Lorsqu'il s'exécute lentement, il utilise une table spool après avoir effectué une recherche sur l'index, lorsqu'il s'exécute rapidement, il ne fait pas la table spool.

En utilisant DBSS SHOW_STATISTICS, j'ai tracé graphiquement l'histogramme d'index dans Excel. Je m'attendrais normalement à ce que le graphique soit plus "vallonné", mais à la place, il ressemble à une montagne, le point le plus élevé étant 2x-3x plus élevé que la plupart des autres valeurs du graphique.

Si je mets à jour des statistiques dessus, sans FULLSCAN, cela semble plus normal. Si je l'exécute à nouveau avec FULLSCAN, cela ressemble à ce que j'ai décrit ci-dessus.

Cela ressemble à un problème de reniflement de paramètres, et spécifiquement lié à la distribution d'index (apparemment) étrange ci-dessus.

Le proc prend un paramètre de valeur de table, un reniflement de paramètre peut-il se produire sur un paramètre de valeur de table?

EDIT: Le proc prend également 12 autres paramètres, dont certains sont facultatifs, dont deux sont une date de début et de fin.

L'histogramme est-il étrange ou aboie-t-il le mauvais arbre?

Je suis certainement à l'aise pour essayer d'ajuster la requête et / ou d'essayer d'ajuster mon indexation. Si c'est le correctif qui est génial, à ce stade, ma question concerne davantage l'histogramme asymétrique.

Je dois mentionner qu'il s'agit d'un index cluster PK IDENTITY. Nous avons deux systèmes qui se parlent, un système hérité, un nouveau système local. Les deux systèmes stockent des données similaires. Pour les garder synchronisés, le PK sur cette table dans le nouveau système est incrémenté lorsque des éléments sont ajoutés à l'ancien système, même si les données ne sont pas transmises (un RESEED est effectué). Il pourrait donc y avoir des lacunes dans la numérotation dans cette colonne. Les enregistrements sont rarement, voire jamais, supprimés.

Toute réflexion serait grandement appréciée. Je suis plus qu'heureux de recueillir / inclure plus d'informations.

Cela a fini par être lié au reniflage des paramètres. Il se trouve que certaines versions étrangement formées de cette requête ont été exécutées juste après la reconstruction des statistiques. Le plan mis en cache n'était donc pas représentatif de la majorité des appels. J'ai utilisé l'astuce de copier les paramètres de date dans des variables locales et cela fonctionne très bien, avec peu ou pas d'impact sur les performances. Cela ne répond pas à la raison pour laquelle l'histogramme semble si "désactivé", mais cela explique mes problèmes de performances.