为什么 DATEADD 会减慢 SQL 查询速度？答案

【问题标题】：Why DATEADD slows down SQL query?为什么 DATEADD 会减慢 SQL 查询速度？
【发布时间】：2014-02-27 07:53:48
【问题描述】：

在我的 SQL Server 查询中，我尝试获取 2 秒的数据范围：

DECLARE @runtime AS datetime
SELECT @runtime = '2014-02-15 03:34:17'

SELECT Application FROM commandcip 
WHERE 
    commandname = 'RunTestCase' AND 
    (createdate BETWEEN DATEADD(s, -1, @runtime) AND DATEADD(s, 1, @runtime))

这个命令非常慢，需要几分钟，基于性能分析器的估计子树成本是 2800。

另一方面，如果我手动计算范围，查询速度非常快（估计子树成本 = 0.5，查询时间

SELECT Application FROM commandcip 
WHERE 
    commandname = 'RunTestCase' AND 
    createdate BETWEEN '2014-02-15 03:34:16' AND '2014-02-15 03:34:18'

我验证了这两个命令都返回了正确的数据。我验证了我的DATEADD 命令返回正确的日期。我也试图让DATEADD 早一步（进入单独的变量@mindate，@maxdate），但它没有帮助。

如何在不手动计算范围的情况下加快第一次查询？

【问题讨论】：

比较执行计划。
使用option (recompile) 允许嗅探变量的值而不是猜测。如果您仍然看到计划中的差异see this
谢谢。选项（重新编译）并没有改进估计计划，但它改进了查询时间......这是重点。如果您将其添加为答案，我会将其标记为已接受。
@jing - 您需要查看实际执行计划，而不是估计。在估计没有分配过SELECT @runtime = '2014-02-15 03:34:17'，所以第二个计划的估计仍然不会使用它。
执行计划比较确认了建议：没有选项（重新编译）它执行昂贵的聚集索引扫描，它使用未指定的@runtime。更快的查询使用 Index Seek 来获取确切的日期。感谢您的解决方案。

标签： sql-server performance tsql

【解决方案1】：

对于createdate BETWEEN '2014-02-15 03:34:16' AND '2014-02-15 03:34:18'，可以在列统计信息中查找文字值以估计将匹配的行数。

除非您使用option (recompile)，否则不会嗅探变量的值，因此 SQL Server 只会使用启发式算法来猜测数字。

大概使用第一个数字得出的计划与使用第二个数字得出的计划不同。

例如一个估计行数较少，并使用带有查找的非覆盖索引，另一个使用完整扫描，因为估计的行数高于tipping point，而这个选项被认为更便宜。

【讨论】：

【解决方案2】：

比较左侧的函数对于 SQL Server 来说就像一个黑盒子。您总是必须尝试将函数向右移动

为了方便开发人员，添加了“between”关键字。查询优化器总是将其重写为双重比较。之间并不比双重比较慢。您可以在使用时看到这一点：在查询顶部设置 STATISTICS PROFILE ON

【讨论】：

我完全不明白这个答案。函数出现的地方（你没有说的左边或右边，但大概是比较的= 符号）并没有产生盲目的差异。即使是这样，在 OPs 查询中，函数调用也在右侧，您声称这是首选位置。

【解决方案3】：

查询执行时间取决于许多因素。

更多，在这种情况下，对 WHERE 子句进行操作，对于每个元组，有点慢是正常的。我的建议是 tru 以改善您的选择。例如添加2个变量，@start datetime = DATEADD(s, -1, @runtime), @end datetime = DATEADD(s, 1, @runtime)，并替换DATEADD(s, -1, @runtime)和DATEADD (s, 1, @runtime)。另一个，有时 between 比双重比较（>=，

【讨论】：

正如我在问题中提到的，我试过了，但没有帮助。我也试过 >