关于 sql server：为什么 T-SQL 变量比较比基于 GETDATE() 函数的比较慢？

Why is a T-SQL variable comparison slower than GETDATE() function-based comparison?

我有一个 T-SQL 语句，我正在对一个包含许多行的表运行。我看到一些奇怪的行为。将 DateTime 列与预先计算的值进行比较比将每一行与基于 GETDATE() 函数的计算进行比较要慢。

以下 SQL 耗时 8 秒：

1
2
3
4
5
6
7
8

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
DECLARE @TimeZoneOffset int = -(DATEPART("HH", GETUTCDATE() - GETDATE()))
DECLARE @LowerTime DATETIME = DATEADD("HH", ABS(@TimeZoneOffset), CONVERT(VARCHAR, GETDATE(), 101) + ' 17:00:00')
SELECT TOP 200 Id, EventDate, Message
FROM Events WITH (NOLOCK)
WHERE EventDate > @LowerTime
GO

这个交替奇怪地立即返回：

1
2
3
4
5
6

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
SELECT TOP 200 Id, EventDate, Message
FROM Events WITH (NOLOCK)
WHERE EventDate > GETDATE()-1
GO

为什么第二个查询这么快？

已编辑：我更新了 SQL 以准确反映我正在使用的其他设置

相关讨论

你检查过执行计划吗？ # 返回的记录数？
EventDate 列上是否有索引？有没有看这两个查询的查询计划？
在这里没有任何区别。我也看不出有任何理由。 GETDATE 每个查询只评估一次，因此一旦查询开始，它的行为与@LowerTime 相同。在您的示例中， GETDATE 和 @LowerTime 的值不同。它们是否都返回相同数量的行？
EventDate 列的类型是什么？
EventDate 上没有索引。我无法比较结果，因为表格在不断增长。我只选择前 200 行。执行计划似乎相同，当然 getdate 比较看起来有点像这样 EventDate > getdate()-\\'1900-01-02 00:00:00.000\\' vs. EventDate > @LowerTime。
@Jon-Seigel EventDate 列是 DateTime 非空值
它不应该多花 8 秒，但您应该知道，转换为 varchar 确实比使用 DateAdd 和 DateDiff 等日期数学需要更长的时间。
如果执行计划不同，原因是 GETDATE()-1 可以与统计信息一起使用，而绑定参数不能。但是，您提到计划似乎是相同的，因此不幸的是，这在这种情况下没有意义。行数估计值在执行计划中是否有所不同？这是上述问题的典型迹象。
@ErikE 同意。但是，在更快的代码中包含变量声明并不会以任何可察觉的方式减慢它。对于较慢的代码，SQL Server 似乎在每次记录比较时都在评估变量分配。
运行跟踪时，读取次数是否相同？
@Markus-Winand 我比较了执行计划的 XML，我能发现的唯一显着差异是 EstimatedTotalSubtreeCost 值 0.14 和 0.43。估计的记录数相同，因为请求了前 200 行。该表有超过 300 万条记录，并且正在加载中。 @ErikE 我无权跟踪。
没有 ORDER BY 的 TOP 不是正确的查询，因此不是正确的测试
@gbn 我删除了订单以查看是否影响性能。无论是 in 还是 out order by 并没有改变使用参数和使用 getdate 计算的区别。
好吧，既然峰值量已经过去，这两个查询现在都可以比较了。我想这可能与我运行查询期间的大量插入有关。奇怪的。不知道我应该如何处理这个问题。
-(DATEPART("HH", GETUTCDATE() - GETDATE())) = DATEDIFF("HH", GETUTCDATE(), GETDATE())。

经过大量阅读和研究，我发现这里的问题是参数嗅探。 Sql Server 尝试根据 where 子句确定如何最好地使用索引，但在这种情况下它做得不是很好。

请看下面的例子：

慢版本：

1
2
3
4
5

declare @dNow DateTime
Select @dNow=GetDate()
Select *
From response_master_Incident rmi
Where rmi.response_date between DateAdd(hh,-2,@dNow) AND @dNow

快速版本：

1
2
3

Select *
From response_master_Incident rmi
Where rmi.response_date between DateAdd(hh,-2,GetDate()) AND GetDate()

"快速"版本的运行速度比慢速版本快 10 倍左右。 Response_Date 字段已编入索引并且是 DateTime 类型。

解决方案是告诉 Sql Server 如何最好地优化查询。如下修改示例以包含 OPTIMIZE 选项导致它使用与"快速版本"相同的执行计划。这里的 OPTMIZE 选项明确告诉 sql server 将本地 @dNow 变量视为日期(好像将其声明为 DateTime 是不够的：s)

在执行此操作时应小心，因为在更复杂的 WHERE 子句中，您最终可能会使查询的性能比 Sql Server 自己的优化更差。

1
2
3
4
5
6
7
8
9
10
11
12

declare @dNow DateTime

SET @dNow=GetDate()

Select ID, response_date, call_back_phone
from response_master_Incident rmi
where rmi.response_date between DateAdd(hh,-2,@dNow) AND @dNow

-- The optimizer does not know too much about the variable so assumes to should perform a clusterd index scann (on the clustered index ID) - this is slow

-- This hint tells the optimzer that the variable is indeed a datetime in this format (why it does not know that already who knows)
OPTION(OPTIMIZE FOR (@dNow = '99991231'));