为什么我的索引查找可以估计正确的行数而排序运算符不能呢？

我有一个查询，该查询在谓词上使用函数，如下所示：

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

我在commentType上有一个经过筛选的索引，该索引具有40K行，当我运行查询时，Index Seek的估计行数非常准确（大约11K），但是对于下一步（sort运算符），它完全忽略了统计信息，仅估算过滤索引中的总行数。

为什么会这样呢？我知道有关可保留性的基础知识，并且为了安全起见，我已经进行了测试，以实际日期（2014-01-01）替换dateadd和voila ...排序开始正确地猜测行数...

为什么会发生这种情况，我该如何解决？我无法通过固定日期...

我相信您的估算是错误的，因为估算器错误会交换两个DATEDIFF参数。我在这里谈论这个：

• 绩效惊喜和假设：DATEDIFF

一种解决方法是不使用DATEDIFF（2008+）来计算13个月前的第一天：

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

我不积极，将解决的估计（我没有与过滤索引测试，我不知道是什么的排序究竟是干什么或为什么它没有计划和/或查询的其余部分不同的估计）。

Microsoft建议的修复程序是使用TF 4199，但是我不确定这是您在这里需要执行的操作：

• Connect＃630583：不正确的估计，条件包括> datediff

另一种选择是确保所使用的任何版本的SQL Server都在绝对最新的SP / CU上，因为他们声称此问题已在下面的知识库文章中得到修复（尽管这仍然需要使用TF 4199除非您的年龄在2014年或以上）：

• KB＃2481274：FIX：使用DATEDIFF函数的查询可能会在SQL Server 2005或SQL Server 2008或SQL Server 2008 R2中缓慢运行

可以使用以下内部版本获得此修复程序：

• 2005 SP3 CU 15（> = 9.00.4325和<= 9.00.4999）
• 2005 SP4 CU 2（> = 9.00.5259）
• 2008 SP1 CU 13（> = 10.00.2816.00 AND <= 10.00.3999）
• 2008 SP2 CU 3（> = 10.00.4279.00 AND <= 10.00.5499）
• 通过扩展2008 SP3和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）
• 通过扩展2008 R2 SP2和SP3（> = 10.50.4000）
• 通过扩展2012、2014、2016（> = 11.0）

（下一次，请SELECT @@VERSION在您的问题中包括结果。）

我将注意到，知识库文章说DATEDIFF可能低估了行数，这与您的方案中发生的情况相反。这并不意味着这些修补程序不适用于您；我认为知识库文章的措词不准确，因为估算值可以根据数据和所要查找的范围进行任意一种选择。

我在上面的博客文章中确认，这种交换不会在2014年及以后发生。为了安全起见，我可能只是从谓词中删除DATEDIFF并使用其他方法来计算范围的开始。我不建议过度使用4199或使用动态SQL来防止错误交换。