查询执行时间异常[关闭]

Question

我在两个不同的环境中执行相同的查询

• 第一个环境有 4GB RAM 和 3.09 Ghz 的 Intel 处理器。
• 第二个环境有 32GB RAM 和 2.20 Ghz 的 AMD 处理器。

我想知道为什么在第一个环境中执行查询需要 6 分钟，而在第二个环境中执行需要很多小时。

我通过执行下面的查询检查了为sql server分配的内存，两个环境具有相同的值。

SELECT value_in_use
FROM sys.configurations
WHERE name = 'max server memory (MB)'

查询在第二种环境中花费太多时间的原因可能是什么？

PS : 两种环境的行数相同（约 200 万）

Answer 1

有几个因素会导致结果不同。我不愿提及它们，因为它们是人们倾向于拒绝的那种东西，但我都经历过它们，并且得到了 msft 的一些确认。

首先，建议您查看执行计划的人是正确的。这可能至少可以让您了解不同之处。

原因（假设数据的大小和内容相同）

1. 两台服务器上的统计数据不同，导致执行计划不同。
2. 硬件性能不同。更慢或更快的 CPU（例如不同的代，即使时钟速度接近），更慢或更快的磁盘。更多内核与一个内核（导致并行计划与串行计划）
3. 硬件配置不同（例如性能差异）。一种使用 SAN，一种具有直接存储。有时很重要。有时一旦数据在缓存中就没有什么区别了。
4. 数据存储在物理上是不同的。一台服务器在您关心的表或索引中具有非常分散和稀疏的数据块/页面。一是紧凑和快速。这可能是由于用于在两个系统中加载数据的不同场景所致。
5. SQLServer 配置设置：例如，一个系统上的有限内存配置。
6. 其中一个系统上存在竞争工作负载。
7. 索引缺失或不同。
8. 不同的排序规则设置导致不同的索引统计和不同的计划。
9. 软件版本略有不同。
10. 数据大小差不多，但内容不同，查询计划变化。

等等

所涉及的时间差异表明很可能有不同的执行计划。

如果所有其他（索引等）都“相同”，有时值得强制 SQLServer 重新运行统计信息，然后再次尝试查询。从历史上看，SQLServer 会根据表中数据的更改量自动更新统计信息。有时这会导致统计信息暂时变差，因为一​​个表达到了更新的阈值，但其他表没有，并且优化器选择了错误的计划。这一切看起来都不太可能，但我曾经构建过一个经常遇到这个问题的产品，并且很幸运地有一位来访的 MSFT SQLServer 开发人员帮助我证明了这一点。

另一个真正打动我的是慢 san 或慢 VMWare 环境。 Sans 通常声称速度很快，但由于网络连接速度慢或工作负载相互竞争，结果却为实际用户提供了糟糕的性能。 VMWare 或其他虚拟化环境通常会导致同样的问题，尤其是在不想弄清楚哪些工作负载正在影响其集群的大型组织中。别人的工作量会影响你的工作量。所以性能测试失去了意义。

我的钱花在了一些改变计划的因素上，比如数据内容、统计数据、索引配置。