使用 OPTION RECOMPILE 时选择日期索引 SEEK，但不使用 OPTION OPTIMIZE FOR

Question

我有一张表，其中包含 10 年的“包扫描”。有人扫描包裹并记录日期和用户名。现在让我们假设保留 10 年的数据实际上是有目的的。

我有一个页面显示过去一周的摘要，所以显然我只想阅读 1 周的数据。

以下是要在 SSMS 中运行两次的查询，一次使用硬编码的最近日期，另一次使用2013 年的旧日期。它最初是一个参数化查询，但在 SSMS 中我用@p0日期替换：

SELECT [t0].[VerifyDate], [t0].[PackageId], [t0].[Username]
FROM [dbo].[PackageVerification] AS [t0]
INNER JOIN [dbo].[Package] AS [t1] ON [t1].[PackageId] = [t0].[PackageId]

WHERE ([t1].[PackageStatus] <> 99) AND ([t0].[VerifyDate] > @p0)   
ORDER BY [t0].[VerifyDate] DESC

在执行之前，我想介绍一下我的日期索引。

现在，我的日期索引不在我的PackageVerification表上，而是在“辅助视图”上，该视图执行与上面所示的相同的连接。上面的查询能够神奇地使用这个索引视图，因为我启用了 SCHEMABINDING。

CREATE NONCLUSTERED INDEX [IX_Helper_PackageVerification_USER_SCAN_HISTORY] ON [dbo].[Helper_PackageVerification]
(
    [VerifyDate] DESC,
    [PackageStatus] ASC
)
INCLUDE (
    [VerifyDateDate],
    [Username]
) 

当我在 SSMS 中使用旧日期和新日期运行查询时，它会按预期使用扫描或查找。阈值似乎在 2015 年左右。所以任何最近的事情肯定都应该使用搜索。这是结果：

当我从应用程序中将其作为参数化查询运行时，我总是会得到完整扫描，由于某种原因它使用并行计划。

至少它正在使用我的辅助索引。

我实际上不确定为什么我没有为此进行参数嗅探。我总是通过一个最近的日期，所以我认为它可能更喜欢扫描，但鉴于情况，我同意它选择上述计划。有超过一百万行，大约需要 150 毫秒。

顺便说一句，这是一个具有 2vCore 的 SQL Azure 数据库。参数嗅探已启用，参数化设置为simple。

如果我更改查询并运行我的应用程序，OPTION (RECOMPILE)我确实可以获得所需的SEEK和仅几毫秒的非常好的性能。重新编译时间似乎可以忽略不计，坦率地说，这是我可以使用的完美性能。

当我查看查询存储时，我可以验证 OPTION RECOMPILE 使用查找最近日期，并扫描旧日期！惊人的。

然而，我以前从未尝试过这一点 - 我想如何进一步改进它OPTION (OPTIMIZE FOR @p0 = '4/1/2021')。

我期望这也能使用搜索，但不需要每次都重新编译。我只是定期更改传递给 OPTIMIZE FOR 的日期 - 也许是上个月月初。

然而，这是查询存储中的查询。

当将日期参数设置为 4/7/21 时，它会对所有超过 100 万行进行全面扫描！

所以现在我迷路了。我已尝试阅读有关该主题的所有内容，但尚未遇到此问题。RECOMPILE 可以工作，但是当我期望 OPTIMIZE FOR 能够有效地模拟在 SSMS 中使用硬编码值运行查询时，它似乎没有做任何事情。

查询计划

第一个计划是唯一一个意想不到的计划——它是一个扫描，我想要一个搜索。

优化 @p1 = '2021/4/1' - https://www.brentozar.com/pastetheplan/?id=H1JB43AUu 优化两个参数 - https://www.brentozar.com/pastetheplan/?id=rkV9U3AUu 选项重新编译 - https://www.brentozar.com/pastetheplan/?id=SJ5cS3CUd

这些是为了证明优化器知道最近的日期应该是一个搜索！

硬编码 2013 - 扫描 - https://www.brentozar.com/pastetheplan/?id=BkeA42RLu 硬编码 2015 - 搜索 - https://www.brentozar.com/pastetheplan/?id=S1c8r3R8O

我开始怀疑这个版本是否不支持 OPTIMIZE FOR，尽管我找不到任何说明不支持的信息

---

编辑：（保罗回答后）

我尝试了一些额外的事情。首先是我之前没有包含的 VIEW 定义。这会执行 JOIN，并且由于它使用 SCHEMABINDING，优化器可以替代它：

使用 SCHEMABINDING AS 创建视图 [dbo].[Helper_PackageVerification]

选择

-- 包验证列 [t0].PackageVerificationId, [t0].Verfied, -- 很久以前的拼写错误！[t0].VerifyDate, -- 这在 [t0] 中不可为空 [t0].Username,

-- 包列 [t1].PackageId、[t1].PackageStatus、[t1].PackedOnDate

FROM [dbo].[PackageVerification] AS [t0]
INNER JOIN [dbo].[Package] AS [t1] ON [t1].[PackageId] = [t0].[PackageId]

WHERE (Verfied = 1 AND verifyDate IS NOT NULL AND PackageStatus <> 99) GO

CLUSTERED 索引已打开PackageVerificationId，主要的非 CLUSTERED 索引如上所示。我实际上创建了六个转换索引来看看它会选择哪个。

1. 我硬编码了PackageStatus <> 99。它原本是一个参数。

2. 我尝试将 NOT NULL 添加到视图上的过滤器中，看看会发生什么。这确实给了我一个 SEEK，但是毫无用处，因为 SEEK 谓词实际上是在VerifyDate IS NOT NULL.

https://www.brentozar.com/pastetheplan/?id=r1HlgF1Dd

您无法将筛选索引添加到索引视图，因此即使视图筛选出 NOT NULL 日期，它也可能无法匹配。那么这可能是我无法将日期用于 SEEK 谓词的最终原因？

2. 在本例中，我没有尝试直接在查询中使用辅助索引，但我非常希望它能与 NOEXPAND 一起使用，就像我在其他地方这样做一样。

Answer 1

使用OPTIMIZE FOR与 不一样OPTION (RECOMPILE)。前者在基数估计中使用提供的参数值来进行计划，该计划可以与其他参数值一起重用。重新编译选项嵌入运行时参数值，并生成一个永远不会重用的一次性计划。

因此，该OPTIMIZE FOR计划需要确保所有可能值的正确操作。重新编译计划可以使用仅对当前值有效的附加优化。它还可以使用仅适用于文字值的优化，例如将过滤器推过窗口函数。

这对于您的情况很重要，因为当OPTIMIZE FOR计划与索引视图匹配时，它会在VerifyDate和PackageStatusIS NOT NULL上添加额外的剩余谓词：

重新编译计划可以删除此逻辑，因为已知提供的值不为空。这些额外隐含谓词的存在足以阻止搜索的索引匹配。通常最好确保源列被限制为不为空，或者在索引视图定义中显式拒绝，以最大限度地减少此类情况。

现在，优化器为您的查询提供了多种计划选择。其中一个迹象是加载的统计对象的数量 - 17。优化器所采取的路径的微小差异可能会产生不同的结果。

从技术上讲，自动索引视图匹配是一个很好的功能，但它确实有局限性。SQL Server 需要添加一些内容并应用特定的重写来实现匹配，这可能会产生意想不到的副作用（请注意上面反向的 @p1 谓词）。匹配后计划也不总是完全清理以匹配针对视图编写的查询将产生的结果。这些不是错误，只是实现细节。

我通常建议人们直接针对视图编写查询并指定提示（NOEXPAND如果可行）。您可能会发现测试以这种方式编写的查询会产生您正在寻找的结果。

我写过的相关文章：

• 参数嗅探、嵌入和 RECOMPILE 选项
• 索引视图和统计数据
• 在企业版中使用 NOEXPAND 提示的另一个原因