Perché il mio indice può cercare di stimare il giusto numero di righe e l'operatore di ordinamento non può?

Ho una query che utilizza una funzione sul predicato, qualcosa del genere:

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

Ho un indice filtrato su commentType che ha 40 K righe e quando eseguo la query, il numero stimato di righe per la Ricerca indice è molto preciso (circa 11 K), ma per il passaggio successivo (operatore di ordinamento) ignora completamente le statistiche e stima solo il numero totale di righe nell'indice filtrato.

Perché sta succedendo? Conosco le basi della sargability e ho testato solo per ragioni di sanità mentale sostituendo il dateadd con una data effettiva (01-01-2014) e voilà ... L'ordinamento ha iniziato a indovinare correttamente il numero di righe ...

Perché sta succedendo e come posso risolverlo? Non riesco a passare una data fissa ...

Credo che le tue stime siano errate a causa di un bug dello stimatore che scambia due degli argomenti DATEDIFF. Ne parlo qui:

• Sorprese e presupposti di prestazione: DATEDIFF

Una soluzione alternativa è calcolare il primo giorno di 13 mesi fa senza utilizzare DATEDIFF (2008+):

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

Io non sono positivi che affronterà la stima (non ho ancora testato con gli indici filtrati, e io non sono sicuro di quello che il genere è in realtà facendo o perché ha una stima diversa senza il piano e / o il resto della query ).

La correzione che Microsoft consiglia è di utilizzare TF 4199, ma non sono così sicuro che è quello che dovrai fare qui:

• Connect # 630583: stima errata con condizione che include> dateiff

Un'altra opzione sarebbe quella di assicurarti di essere sull'ultimo SP / CU assoluto per qualsiasi versione di SQL Server che stai utilizzando, poiché sostengono che sia stato risolto nel seguente articolo KB (anche se ciò richiederà comunque l'uso di TF 4199 a meno che tu non sia nel 2014 o meglio):

• KB # 2481274: FIX: una query che utilizza la funzione DATEDIFF può essere eseguita lentamente in SQL Server 2005 o in SQL Server 2008 o in SQL Server 2008 R2

La correzione può essere ottenuta con le seguenti build:

• 2005 SP3 CU 15 (> = 9.00.4325 E <= 9.00.4999)
• 2005 SP4 CU 2 (> = 9.00.5259)
• 2008 SP1 CU 13 (> = 10.00.2816.00 E <= 10.00.3999)
• 2008 SP2 CU 3 (> = 10.00.4279.00 E <= 10.00.5499)
• Per estensione 2008 SP3 e SP4 (> = 10.00.5500)
• 2008 R2 CU 7 (10.50.1777.0)
• 2008 R2 SP1 CU 3 (> = 10.50.2769.0 E <= 10.50.3999)
• Per estensione 2008 R2 SP2 e SP3 (> = 10.50.4000)
• Per estensione 2012, 2014, 2016 (> = 11.0)

(La prossima volta, includi i risultati della SELECT @@VERSIONtua domanda.)

Noterò che l'articolo di KB dice che DATEDIFF può sottovalutare il numero di righe, che è l'opposto di ciò che sta accadendo nel tuo scenario. Ciò non significa che le correzioni non si applichino a te; Penso che la formulazione dell'articolo KB sia imprecisa, poiché le stime possono andare in entrambi i modi a seconda dei dati e dell'intervallo che stai osservando.

Il mio post sul blog sopra ha confermato che lo scambio non si verifica più nel 2014 e fino. Per sicurezza, probabilmente eliminerei DATEDIFF dal tuo predicato e utilizzerei un metodo diverso per calcolare l'inizio del tuo intervallo. Non suggerisco l'overkill di 4199 o l'utilizzo di SQL dinamico per impedire lo scambio errato.