¿Por qué mi búsqueda de índice puede estimar el número correcto de filas y el operador de clasificación no puede?

Tengo una consulta que usa una función en el predicado, algo como esto:

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

Tengo un índice filtrado en commentType que tiene 40K filas y cuando ejecuto la consulta, el número estimado de filas para Index Seek es muy preciso (alrededor de 11K), pero para el siguiente paso (operador de clasificación) ignora por completo las estadísticas y solo estima el número total de filas en el índice filtrado.

¿Por qué está pasando esto? Sé lo básico sobre la sargabilidad , y lo probé solo por razones de cordura, reemplazando el dateadd por una fecha real (01-01-2014) y listo ... El tipo comenzó a adivinar el número de filas correctamente ...

¿Por qué sucede esto y cómo puedo solucionarlo? No puedo pasar una fecha fija ...

Creo que sus estimaciones son incorrectas debido a un error del estimador que intercambia dos de los argumentos DATEDIFF. Hablo de esto aquí:

• Sorpresas y supuestos de rendimiento: DATEDIFF

Una solución alternativa es calcular el primer día de hace 13 meses sin usar DATEDIFF (2008+):

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

No estoy seguro de que abordará la estimación (no he probado con índices filtrados, y no estoy seguro de qué está haciendo realmente el tipo o por qué tiene una estimación diferente sin el plan y / o el resto de la consulta )

La solución que Microsoft recomienda es usar TF 4199, pero no estoy tan seguro de que sea lo que deba hacer aquí:

• Connect # 630583: Estimación incorrecta con condición que incluye>

Otra opción sería asegurarse de estar en el último SP / CU absoluto para cualquier versión de SQL Server que esté utilizando, ya que afirman que está solucionado en el siguiente artículo de KB (aunque esto aún requerirá el uso de TF 4199 a menos que esté en 2014 o mejor):

• KB # 2481274: REVISIÓN: una consulta que utiliza la función DATEDIFF puede ejecutarse lentamente en SQL Server 2005 o en SQL Server 2008 o en SQL Server 2008 R2

La solución se puede obtener con las siguientes compilaciones:

• 2005 SP3 CU 15 (> = 9.00.4325 Y <= 9.00.4999)
• 2005 SP4 CU 2 (> = 9.00.5259)
• 2008 SP1 CU 13 (> = 10.00.2816.00 Y <= 10.00.3999)
• 2008 SP2 CU 3 (> = 10.00.4279.00 Y <= 10.00.5499)
• Por extensión 2008 SP3 y SP4 (> = 10.00.5500)
• 2008 R2 CU 7 (10.50.1777.0)
• 2008 R2 SP1 CU 3 (> = 10.50.2769.0 Y <= 10.50.3999)
• Por extensión 2008 R2 SP2 y SP3 (> = 10.50.4000)
• Por extensión 2012, 2014, 2016 (> = 11.0)

(La próxima vez, incluya los resultados de SELECT @@VERSIONen su pregunta).

Notaré que el artículo de KB dice que DATEDIFF puede subestimar el número de filas, que es lo contrario de lo que está sucediendo en su escenario. Eso no significa que las correcciones no se apliquen a usted; Creo que la redacción del artículo de KB es inexacta, ya que las estimaciones pueden ir en cualquier dirección dependiendo de los datos y el rango que esté viendo.

Mi publicación de blog anterior confirmó que el intercambio ya no se produce en 2014 o más. Para estar seguro, probablemente simplemente eliminaría DATEDIFF de su predicado y usaría un método diferente para calcular el comienzo de su rango. No sugiero la exageración de 4199 o el uso de SQL dinámico para evitar el intercambio incorrecto.