这个日期比较条件在SQL中是否可以SARG?

前端之家收集整理的这篇文章主要介绍了这个日期比较条件在SQL中是否可以SARG?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
这种情况是否可以接受?
AND  DATEDIFF(month,p.PlayerStatusLastTransitionDate,@now) BETWEEN 1 AND 7)

我的经验法则是左边的一个函数使条件不可思议..但在某些地方我已经读过BETWEEN子句是sargable.
那么任何人都知道吗?

以供参考:

> What makes a SQL statement sargable?
> http://en.wikipedia.org/wiki/Sargable

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

解决方法

使用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,GETDATE());

我们看到了很大的不同 – 后者使用了寻求:

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

极少数情况下,应用于列的函数或其他表达式将是可搜索的.我所知道的一个案例是CONVERT(DATE,datetime_column) – 但是这个特定的优化是没有记录的,我建议远离它.不仅因为你暗中暗示对列使用函数/表达式是可以的(它不是在所有其他场景中),而且因为it can lead to wasted reads and disastrous estimates.

猜你在找的MsSQL相关文章