这个日期比较条件是SQL中的SARG-able吗？

Question

这种情况是否可以接受？

AND  DATEDIFF(month,p.PlayerStatusLastTransitionDate,@now) BETWEEN 1 AND 7)

我的经验法则是左边的一个函数使条件不可思议..但在某些地方我已经读过BETWEEN子句是可以理解的. 所有人都知道吗？

以供参考:

• 是什么让SQL语句变得可思议？
• http://en.wikipedia.org/wiki/Sargable

注意:如果任何大师在此结束,请更新Sargable Wikipedia页面.我更新了一点,但我相信它可以改进:)

Answer 1

使用AdventureWorks,如果我们查看这两个等效查询:

SELECT OrderDate FROM Sales.SalesOrderHeader
WHERE DATEDIFF(month,OrderDate,GETDATE()) BETWEEN 1 AND 7;

SELECT OrderDate FROM Sales.SalesOrderHeader
WHERE OrderDate >= DATEADD(MONTH, -7, GETDATE())
  AND OrderDate <= DATEADD(MONTH, -1, GETDATE());

在这两种情况下,我们都会看到聚集索引扫描:

但请注意后一个查询的推荐/缺失索引,因为它是唯一可以从中受益的索引:

如果我们向OrderDate列添加索引,则再次运行查询:

CREATE INDEX dt ON Sales.SalesOrderHeader(OrderDate);
GO

SELECT OrderDate FROM Sales.SalesOrderHeader
WHERE DATEDIFF(month,OrderDate,GETDATE()) BETWEEN 1 AND 7;

SELECT OrderDate FROM Sales.SalesOrderHeader
WHERE OrderDate >= DATEADD(MONTH, -7, GETDATE())
  AND OrderDate <= DATEADD(MONTH, -1, GETDATE());

我们看到很多不同 - 后者使用了一个寻求:

另请注意,您的查询版本的估算值如何.这对于大型数据集来说绝对是灾难性的.

极少数情况下,应用于列的函数或其他表达式将是可搜索的.我知道的一个案例是CONVERT(DATE, datetime_column)- 但是这个特定的优化没有记录,我建议不要再远离它了.不仅因为你暗中暗示对列使用函数/表达式是可以的(它不是在所有其他场景中),而且还因为它可能导致浪费的读取和灾难性的估计.

Answer 2

如果这是可以理解的,我会非常惊讶.一种选择可能是将其重写为:

WHERE p.PlayerStatusLastTransitionDate >= DATEADD(month,1,CAST(@now AS DATE))
AND   p.PlayerStatusLastTransitionDate <= DATEADD(month,7,CAST(@now AS DATE))

我认为这将是可靠的(即使它不是那么漂亮).