Pourquoi mon index peut-il estimer le bon nombre de lignes et l'opérateur de tri ne peut pas?

J'ai une requête qui utilise une fonction sur le prédicat, quelque chose comme ceci:

commentType = 'EL'
AND commentDateTime >= DATEADD(month,datediff(month,0,getdate()) - 13,0)

J'ai un index filtré sur commentType qui a 40K lignes et lorsque j'exécute la requête, le nombre estimé de lignes pour la recherche d'index est très précis (environ 11K), mais pour l'étape suivante (opérateur de tri), il ignore complètement les statistiques et estime simplement le nombre total de lignes dans l'index filtré.

Pourquoi cela arrive-t-il? Je connais les bases de la sargabilité , et j'ai testé juste pour le bien de la raison en remplaçant le dateadd par une date réelle (2014-01-01) et le tour est joué ... Le tri a commencé à deviner le nombre de lignes correctement ...

Pourquoi cela se produit-il et comment puis-je le corriger? Je ne peux pas passer une date fixe ...

Je crois que vos estimations sont fausses à cause d'un bug d'estimateur qui permute deux des arguments DATEDIFF. J'en parle ici:

• Surprises et hypothèses de rendement: DATEDIFF

Une solution de contournement consiste à calculer le premier jour d'il y a 13 mois sans utiliser DATEDIFF (2008+):

DATEADD(MONTH, -13, DATEADD(DAY, 1-DATEPART(DAY,GETDATE()), CONVERT(DATE, GETDATE()));

Je ne suis pas positif qui répondra à l'estimation (je ne l' ai pas testé avec des index filtrés, et je ne suis pas sûr de ce que le genre est en train de faire ou pourquoi il a une estimation différente sans le plan et / ou le reste de la requête ).

Le correctif recommandé par Microsoft consiste à utiliser TF 4199, mais je ne suis pas sûr que ce soit ce que vous devrez faire ici:

• Connect # 630583: Estimation incorrecte avec une condition qui inclut> dateiff

Une autre option serait de vous assurer que vous êtes sur le dernier SP / CU absolu pour la version de SQL Server que vous utilisez, car ils prétendent que cela est résolu dans l'article de la base de connaissances suivant (bien que cela nécessitera toujours l'utilisation de TF 4199 sauf si vous êtes en 2014 ou mieux):

• KB # 2481274: CORRECTIF: une requête qui utilise la fonction DATEDIFF peut s'exécuter lentement dans SQL Server 2005 ou SQL Server 2008 ou SQL Server 2008 R2

Le correctif peut être obtenu avec les versions suivantes:

• 2005 SP3 CU 15 (> = 9.00.4325 ET <= 9.00.4999)
• 2005 SP4 CU 2 (> = 9.00.5259)
• 2008 SP1 CU 13 (> = 10.00.2816.00 ET <= 10.00.3999)
• 2008 SP2 CU 3 (> = 10.00.4279.00 ET <= 10.00.5499)
• Par extension 2008 SP3 & SP4 (> = 10.00.5500)
• 2008 R2 CU 7 (10.50.1777.0)
• 2008 R2 SP1 CU 3 (> = 10.50.2769.0 ET <= 10.50.3999)
• Par extension 2008 R2 SP2 & SP3 (> = 10.50.4000)
• Par extension 2012, 2014, 2016 (> = 11,0)

(La prochaine fois, veuillez inclure les résultats de SELECT @@VERSIONdans votre question.)

Je noterai que l'article de la base de connaissances dit que DATEDIFF peut sous - estimer le nombre de lignes, ce qui est l'opposé de ce qui se passe dans votre scénario. Cela ne signifie pas que les correctifs ne s'appliquent pas à vous; Je pense que le libellé de l'article de la base de connaissances est inexact, car les estimations peuvent aller dans les deux sens en fonction des données et de la plage que vous regardez.

Mon article de blog ci-dessus a confirmé que l'échange ne se produit plus en 2014 et après. Pour être sûr, je supprimerais probablement DATEDIFF de votre prédicat et utiliserais une méthode différente pour calculer le début de votre plage. Je ne suggère pas la surpuissance de 4199 ou l'utilisation de SQL dynamique pour empêcher le mauvais échange.