DECLARE 与直接日期时间转换性能比较

Question

我试图了解声明日期时间转换变量并使用它与直接在 SQL Server 查询中转换日期之间是否存在任何性能差异。

以下是两个示例查询： 查询 1：每次都进行日期时间转换

SELECT * 
FROM TestMessages
WHERE CreatedDate > CONVERT(DATETIME, '2023-12-18 00:00:00', 120);

查询 2：声明日期时间转换变量

DECLARE @yourDateString NVARCHAR(19) = '2023-12-18 00:00:00';
DECLARE @ConvertedDate DATETIME = CONVERT(DATETIME, @yourDateString, 120);

SELECT * 
FROM TestMessages
WHERE CreatedDate > @ConvertedDate;

这两个查询之间有明显的性能差异吗？声明日期时间转换变量如何影响查询的执行时间？此外，可以使用哪些 SQL Server 工具或技术来分析和衡量这种性能差异？

我一直在 SQL Server 查询中尝试两种不同的方法来进行日期时间转换。在一个查询中，我直接转换日期时间值，在另一个查询中，我使用 DECLARE 创建转换变量。我预计会观察到这两种方法之间潜在的性能差异，但结果并不像我预期的那么清晰。我想了解这些方法对性能的影响以及优化 SQL Server 查询中的日期时间转换的任何推荐实践。

当我检查执行计划时，计划似乎存在差异，但尚不清楚它是否重要。此外，当我查看统计信息时，第一个查询显示“88 行受影响”，而另一个查询显示“1 行受影响”。第一个查询的成本显示为 100% 和 0.000 秒，其中“88 行中的 88 行 (0%) 受到影响”。但是，对于第二个查询，成本也是 100%，但“0.000s 0 of 855 (0%)”行受到影响。这种差异显着吗？

Answer 1

和

WHERE CreatedDate > CONVERT(DATETIME, '2023-12-18 00:00:00', 120);

基数估计可能会更准确。

这将提高获得适当计划以及潜在内存授予的机会。

对于CreatedDate > @ConvertedDate谓词，它只会假设 30% 匹配，除非您还使用OPTION (RECOMPILE)允许它嗅探变量的值。

因为CreatedDate > CONVERT(DATETIME, '2023-12-18 00:00:00', 120)它可以在直方图中查找该值并从中获得估计值。

CREATE TABLE TestMessages
             (
                          CreatedDate DATETIME INDEX ix_CreatedDate,
                          Filler      CHAR(1000) NULL
             )
INSERT TestMessages
       (CreatedDate)
SELECT DATEADD(HOUR, value, '1990-01-01 00:00:00')
FROM   generate_series(1, 300000) 

WHERE CreatedDate > CONVERT(DATETIME, '2023-12-18 00:00:00', 120);

WHERE CreatedDate > @ConvertedDate

WHERE CreatedDate > @ConvertedDate 选项（重新编译）；