OPTION FORCE ORDER提高性能，直到删除行

我有一个稍微复杂的SQL Server 2008查询（大约200行相当密集的SQL），但没有按照我的需要执行。随着时间的流逝，性能从大约0.5秒下降到大约2秒。

看一下执行计划，很明显，通过重新排序联接，可以提高性能。我做到了，而且做到了……下降到约0.3秒。现在，该查询具有“ OPTION FORCE ORDER”提示，并且生活很顺利。

今天，我来了，清理数据库。我存档了大约20％的行，除了删除行外，在相关数据库中不执行任何操作...执行计划的执行总数为软管。它会完全判断某些子树将返回多少行，并且（例如）替换为：

<Hash>

与

<NestedLoops Optimized='false' WithUnorderedPrefetch='true'>

现在，查询时间从大约0.3秒增加到大约18秒。（！）只是因为我删除了行。如果删除查询提示，我将返回大约2秒的查询时间。更好，但是更糟。

将数据库还原到多个位置和服务器后，我重现了该问题。简单地从每个表中删除大约20％的行总是会导致此问题。

1. 对于强制联接顺序来说，使查询估计完全不准确（从而使查询时间无法预测）是否正常？
2. 我应该只是希望我要么必须接受次优的查询性能，要么像鹰一样看着它并经常手动编辑查询提示？还是暗示每个联接？.3s至2s是一个很大的选择。
3. 很明显，为什么优化器在删除行后就炸毁了？例如，“是的，它进行了一次样本扫描，并且由于我在数据历史记录中较早地归档了大多数行，因此样本产生了稀疏的结果，因此它低估了对排序后的哈希操作的需要”？

如果您想查看执行计划，请建议一个可以张贴它们的位置。否则，我将采样最惊人的部分。这是基本的错误估计，paren中的数字是（估计：实际）行。

                             /  Clustered Index Scan (908:7229)
Nested Loops (Inner Join) --<
                             \  NonClustered Index Seek (1:7229)

请注意，内部循环应扫描908行，但扫描52,258,441。如果准确，则此分支将运行约2毫秒，而不是12秒。在删除行之前，此内部联接估计值的总和仅为2，并且对两个聚簇索引进行哈希匹配。

对于强制联接顺序来说，使查询估计完全不准确（从而使查询时间无法预测）是否正常？

使用FORCE ORDER不会使估算不准确，删除行确实可以使估算不准确。强制更新表上的统计信息可以提高估计准确性。

我应该只是希望我要么必须接受次优的查询性能，要么像鹰一样看着它并经常手动编辑查询提示？还是暗示每个联接？.3s至2s是一个很大的选择。

最好是确保在不使用FORCE ORDER提示的情况下，为优化器提供生成最佳计划所需的信息。这样，它应该更好地应对基础数据分布的更改，而无需手动干预。就是说，如果数据的性质使得基数每小时或每小时的小时变化很大，请考虑使用计划指南以确保计划是固定的。

很明显，为什么优化器在删除行后就炸毁了？例如，“是的，它进行了一次样本扫描，并且由于我在数据历史记录中较早地归档了大多数行，因此样本产生了稀疏的结果，因此它低估了对排序后的哈希操作的需要”？

您没有在问题表中提及行数，但是删除的原因可能是：

• 没有删除足以触发统计信息更新的行。当已修改20％的行，但可以选择使用跟踪标志2371启用动态阈值时，就会发生这种情况。
• 确实触发了统计信息更新，但是收集的样本并不具有代表性。通过使用FULLSCAN运行手动更新来更正此问题。

您也可能会遇到老式的参数嗅探问题，需要解决许多问题。使用如此大的查询来指定WITH RECOMPILE可能是一个昂贵的选择，但值得在过程和语句级别进行研究。