SQL 性能：MSSQL 是否优化了日期时间函数的使用，还是将其作为参数传递更好

如何解决SQL 性能：MSSQL 是否优化了日期时间函数的使用，还是将其作为参数传递更好

我编写了这个相当简单的查询，其中我根据名为 LastActivity 的 DateTimeOffset 列选择不到 5 分钟的记录。

我正在使用 EF，在检查实际查询时，我发现 EF 实际上转换了这个条件： LastActivity > DateTimeOffset.UtcNow.AddMinutes(-5); 到使用 SQL 日期时间函数的查询：[s].[LastActivity] > DATEADD(minute,CAST(-5.0E0 AS int),CAST(SYSUTCDATETIME() AS datetimeoffset))。

如您所见，它执行了一些不必要的转换（例如 .AddMinutes 需要一个 double），所以我想知道首先在代码中实际计算 DateTime 然后将结果作为查询传递给查询是否会更高效范围。 我知道这将取决于统计数据，我还不能真正说出这些值将如何分布...... 我已经在一个示例数据库上运行了这两个查询，并且性能没有真正的差异，但是当数据集增加时，我认为这可能会改变。

我的问题是：我是否正确假设当没有参数（但使用 DATEADD）时，SQL 将始终使用相同的查询计划，或者它会以某种方式优化它，因为我们使用的是 SYSUTCDATETIME？

解决方法

EF 为该查询提供的内容可以正常工作，即使它有一些意外的语法。

为什么？

1. WHERE timestampcolumn > DATEADD(minute,number,something_meaning_now) 是一个 sargeable 过滤词：它可以使用 timestampcolumn 上的索引。
2. SYSUTCDATETIME() 是一个非确定性函数。这意味着 SQL Server 知道它的返回值基于除输入值之外的其他值。

所以，这就是正在发生的事情：SQL Server 在使用它之前“在代码中”计算日期，就像您在代码中所做的那样。因为 SQL Server 知道每次使用查询时计算出的日期都会改变（因为它是不确定的），所以它的缓存执行计划不会将该日期绑定到一个常量，因此查询缓存不会膨胀。如果您的过滤器是 timestampcolumn < DATEADD(minute,'2021-01-23 12:34')，它将被绑定。

我已经在大规模生产中做了很多这样的事情并且它工作正常。

您询问了扩大规模。这样做的方法是在 s.LastActivity 列上放置一个索引。但是，要弄清楚您需要哪些索引...

1. 使用 SSMS
2. 选择显示实际查询计划。
3. 运行查询
4. 查看查询计划。如果您需要，它会显示推荐的索引。