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

【问题标题】：Same query, different execution plans相同的查询，不同的执行计划
【发布时间】：2010-05-25 11:45:41
【问题描述】：

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

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

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

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

谢谢， A.

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

【问题讨论】：

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

HTH

【讨论】：

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

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

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

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

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

【讨论】：