Por que meu índice procura estimar o número certo de linhas e o operador de classificação não pode?

Eu tenho uma consulta que usa uma função no predicado, algo como isto:

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

Eu tenho um índice filtrado no commentType que tem 40K linhas e, quando executo a consulta, o número estimado de linhas para a Busca por Índice é muito preciso (em torno de 11K), mas para a próxima etapa (operador de classificação) ele ignora completamente as estatísticas e apenas estima o número total de linhas no índice filtrado.

Por que isso está acontecendo? Eu sei o básico sobre sargabilidade e testei apenas por uma questão de sanidade, substituindo os dados datados por uma data real (01-01-2014) e pronto ... O tipo começou a adivinhar o número de linhas corretamente ...

Por que isso está acontecendo e como posso corrigi-lo? Não posso passar uma data fixa ...

Acredito que suas estimativas estão erradas por causa de um bug no estimador que troca dois dos argumentos DATEDIFF. Eu falo sobre isso aqui:

• Surpresas e premissas de desempenho: DATEDIFF

Uma solução alternativa é calcular o primeiro dia de 13 meses atrás sem usar DATEDIFF (2008 ou posterior):

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

Não tenho certeza de que abordará a estimativa (não testei com índices filtrados e não sei o que a classificação está realmente fazendo ou por que ela tem uma estimativa diferente sem o plano e / ou o restante da consulta )

A correção que a Microsoft recomenda é usar o TF 4199, mas não tenho certeza de que você precisará fazer aqui:

• Connect # 630583: Estimativa incorreta com condição que inclui> data datada

Outra opção seria garantir que você esteja no SP / CU mais recente absoluto para qualquer versão do SQL Server que estiver usando, pois eles alegam que o problema foi corrigido no seguinte artigo da KB (embora isso ainda exija o uso do TF 4199 a menos que você esteja em 2014 ou melhor):

• KB # 2481274: CORRECÇÃO: Uma consulta que usa a função DATEDIFF pode ser executada lentamente no SQL Server 2005 ou no SQL Server 2008 ou no SQL Server 2008 R2

A correção pode ser obtida com as seguintes compilações:

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

(Da próxima vez, inclua os resultados de SELECT @@VERSIONem sua pergunta.)

Observarei que o artigo da KB diz que DATEDIFF pode subestimar o número de linhas, que é o oposto do que está acontecendo no seu cenário. Isso não significa que as correções não se aplicam a você; Acho que a redação do artigo da KB é imprecisa, pois as estimativas podem variar de acordo com os dados e o intervalo que você está olhando.

Meu post acima confirmou que a troca não ocorre mais em 2014 e acima. Para estar seguro, provavelmente retiraria DATEDIFF do seu predicado e usaria um método diferente para calcular o início do seu intervalo. Não sugiro o exagero de 4199 ou o uso de SQL dinâmico para impedir a troca incorreta.