相同的查询，不同的执行计划

Posted 2023-04-13

【中文标题】相同的查询，不同的执行计划

【英文标题】：Same query, different execution plans

【发布时间】：2010-05-25 11:45:41

【问题描述】：

我正在努力寻找一个让我发疯的问题的解决方案......

我有一个查询，它在 QA 服务器中运行得非常快，但在生产中却很慢。我意识到他们有不同的执行计划......所以我尝试重新编译，清理执行计划的缓存，更新统计信息，检查排序规则......但我仍然找不到正在发生的事情......

运行查询的数据库完全相同，SQL Server 也具有相同的配置。

任何新想法都将不胜感激。

谢谢， A.

---

我刚刚意识到 QA 服务器运行的是 SP3，而生产中的是 SP2。这会对这个问题有什么影响吗？

【问题讨论】：

这两种环境的硬件是否完全相同？ in 数据库中的数据在两个环境之间是否完全相同？

【参考方案1】：

生产服务器是否有可能拥有更大的数据库大小？该计划可能会有所不同，因为它基于对其包含的数据的统计信息。

【参考方案2】：

我认为这可能是由于存在的数据量。有一次我们遇到过这种情况，查询实际上是在 QA 服务器中运行，但在生产中却非常缓慢。经过一段时间的思考，我们发现 QA 服务器有 15K 行，而生产有 150 万行。

HTH

【讨论】：

不，两个数据库完全相同...相同的表、触发器、索引...和数据...

【参考方案3】：

如果执行计划相同但速度较慢，则可能是数据库负载、硬件、锁定/阻塞等。

但是，如果执行计划不同，则两个数据库之间会有所不同。两者的统计数据是否都是最新的，具有完全相同的架构、相同的索引、相似的行数、相同的 PK 和索引值分布等。QA 数据来自哪里，随机数据还是从生产中恢复？

【讨论】：

QA 数据库是从生产数据库手动备份/恢复的，所以我认为一切都应该是一样的，对吧？我只是不明白我得到了不同的执行计划......

而且执行上的差异简直是虚幻的......一个查询在 QA 中需要 3 秒，而在生产中则需要将近 5 分钟......

发布执行计划怎么样？或者至少告诉实际差异是什么

当然可以，但我认为它们太大了，无法在此处发布...我可以发给你吗？

【参考方案4】：

在生产环境中禁用并行查询执行 :)

【讨论】：

在生产中？这取决于数据库和查询性质；对于我们的主要应用程序，通常最好关闭并行性，但可以肯定的是，在某些情况下，并行性会有所帮助。

【参考方案5】：

我最近遇到了这个问题，这就是我发现的。

我有两个数据库，它们基本上是彼此的副本。在一个版本中，TVF 需要 1 秒才能运行，而在另一个版本中需要 15 分钟。

底层 SQL 代码的执行计划非常不同。我能够通过重建 TVF 所依赖的一些索引来修复它。执行计划不一样，但确实发生了很大变化。执行时间又回落到一秒左右。

现在，两个版本的索引都高度分散。我的假设是历史统计或执行计划信息允许快速版本继续找到最佳执行计划。

总结一下：确保查看索引的碎片，即使它们具有相同的结构或相似的碎片率。