8

我正在努力为让我发疯的问题找到解决方案......

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

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

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

谢谢。


我刚刚意识到 QA 服务器正在运行 SP3,而生产中是 SP2。这对这个问题有什么影响吗?

4

5 回答 5

2

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

于 2010-05-25T11:52:46.493 回答
2

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

高温高压

于 2010-05-25T11:55:23.547 回答
1

如果执行计划相同并且执行计划很慢,则可能是数据库负载、硬件、锁定/阻塞等。

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

于 2010-05-25T12:14:06.567 回答
0

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

于 2010-05-25T12:17:49.240 回答
0

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

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

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

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

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

于 2012-05-16T15:13:58.017 回答