在很多地方使用 GETDATE() 时，使用变量是否更好？

Question

更好，我的意思是它是否通过一些非边际量提高了性能？

也就是说，每次我调用GETDATE() ，服务器做了多少工作来返回该值？

如果我在存储过程的许多地方使用GETDATE() ，我是否应该创建一个变量来存储事务的日期？

declare @transDate datetime = GETDATE()

基准数据会很棒。

编辑我想澄清一下：我主要对这两种可能性之间的实际性能差异感兴趣，以及它是否重要。

Answer 1

[注意：如果您要否决此答案，请发表评论解释原因。 它已经被否决了很多次，最后 ypercube（谢谢）至少解释了一个原因。 我无法删除答案，因为它已被接受，因此您不妨帮助改进它。]

根据 Microsoft 上的这种交流， GETDATE()从查询中的常量切换到 SQL Server 2005 中的非确定性。 回想起来，我认为这并不准确。 我认为它在 SQL Server 2005 之前是完全非确定性的，然后自 SQL Server 2005 起就被称为“非确定性运行时常量”。后面的短语似乎真的意味着“查询中的常量”。

（并且GETDATE()被定义为明确且自豪的非确定性，没有限定符。）

唉，在 SQL Server 中，不确定性并不意味着对每一行都评估一个函数。 SQL Server 确实使这变得不必要地复杂和模棱两可，关于该主题的文档很少。

实际上，函数调用是在查询运行时计算的，而不是在查询编译时计算一次，每次调用它的值都会改变。 在实践中， GETDATE()只为每个使用它的表达式计算一次——在执行时而不是编译时。 但是，Microsoft 将rand()和getdate()归入一个特殊类别，称为非确定性运行时常量函数。 相比之下，Postgres 不会跳过这样的圈套，它只是调用在“稳定”执行时具有恒定值的函数。

尽管 Martin Smith 发表了评论，但 SQL Server 文档在这个问题上并没有明确说明GETDATE()被描述为“非确定性”和“非确定性运行时常量”，但并未真正解释该术语。 例如， 我发现术语 的一个地方，文档中的下一行说不要在子查询中使用非确定性函数。 对于“非确定性运行时常量”，这将是愚蠢的建议。

我建议即使在查询中也使用带有常量的变量，这样你就有一个一致的值。 这也使意图非常明确：您需要查询中的单个值。 在单个查询中，您可以执行以下操作：

select . . . 
from (select getdate() as now) params cross join
     . . . 

实际上，这是一个建议，只应在查询中评估一次，但可能有例外。 出现混淆是因为getdate()在所有不同的行上返回相同的值——但它可以在不同的列中返回不同的值。 每个带有getdate()表达式都是独立计算的。 如果您运行，这很明显：

select rand(), rand()
from (values (1), (2), (3)) v(x);

在存储过程中，您可能希望变量中有一个值。 如果在午夜过去时运行存储过程，并且日期发生变化，会发生什么情况？ 这对结果有什么影响？

至于性能，我的猜测是日期/时间查找是最小的，并且当查询开始运行时，每个表达式都会发生一次查询。 这不应该是真正的性能问题，而更像是代码一致性问题。

Answer 2

我的建议是使用变量，主要是因为如果您有一个长时间运行的进程，则GetDate()值可能因调用而异。

除非您只使用GetDate()的Date部分， GetDate()您将确保始终使用相同的值。

Answer 3

将变量与getdate()或suser_sname()类的函数一起使用的一个原因是，如果您正在插入行，或者您正在执行GROUP BY ，则性能会有很大差异。 如果插入大量行，您会注意到这一点。

我自己在将 300GB 的数据迁移到几个表时遇到了这种情况。

Answer 4

我正在使用 GETDATE() 函数作为 SP 中的变量测试几个存储过程，并且由于查询优化器不知道操作读取这个存储的值是什么，我增加了 IO 读取和执行时间带有参数、变量和文字的过程执行，也就是说你可以在 SP 的每个部分使用 GETDATE() 函数，因为@Gordon Linoff提到它的值在执行过程中不会改变，或者为了避免/消除这种想法值可能会改变我确实以这种方式创建了一个参数：

CREATE PROC TestGetdate
(
@CurrentDate DATETIME = NULL
)
AS
SET CurrentDate  = GETDATE()

..... 然后使用你认为合适的参数，你会看到很好的结果

欢迎任何意见或建议。

Answer 5

我用了

WHERE ActualDateShipped+30 > dbo.Today()

结合下面的功能。 使我的查询时间从 13 秒缩短到 2 秒。 这篇文章中没有先前的答案可以帮助 SQL 2008/R2 中的这个问题。

CREATE FUNCTION [dbo].[Today]()

    RETURNS date
    AS
    BEGIN

        DECLARE @today date = getdate()

        RETURN @today
    End