我在客户的生产环境中遇到了一个奇怪的问题。我无法提供有关基础架构的任何详细信息，除了 SQL 服务器在虚拟服务器上运行。数据、日志和文件流文件位于另一台存储服务器上（数据和文件流在一起，日志在单独的服务器上）。
在我们的本地测试环境中，有一个特定查询以以下持续时间执行：
- 首先我们清除缓存
- 300 毫秒（第一次需要更长时间，但从那时起它就被缓存了。）
- 20毫秒
- 15毫秒
- 17毫秒
在客户的生产环境中，SQL Server 更强大，这些是持续时间（我没有清除缓存的权限。明天会尝试一下）。
- 2500毫秒
- 2600毫秒
- 2400毫秒
客户生产环境中的服务器功能更强大，但他们确实有虚拟服务器（我们没有）。
可能是什么原因...
- 内存不足？
- 碎片化？
- 物理存储？
您将如何解决这个性能问题？
编辑：
有些人问我数据集是否相等，答案是肯定的。我在我们的环境中恢复了他们的数据库。确实，这是我首先看到的东西。（@Everyone：我添加了编辑，因为这将是许多人首先想到的东西）。
答案1
原因可能是内存不足、碎片、物理存储，以及并行度设置不同、争用、表大小不同、统计数据不同、SQL 补丁级别不同等等。
所以实际上不是一个关于什么是错误的，而是如何确定哪里出了问题。我通常的建议，基本上不是“根据我的经验，这或者那，就是使用等待和排队方法。这是一种相当有效的方法，最终可以找出罪魁祸首，然后找到解决方案。
答案2
这可能是内存、CPU、网络或磁盘争用，但是客户的数据集是否更大？
您的第一步是获取查询本身的执行计划，以确保它不会扫描行。您确实应该先优化查询，因为您已经说过他们的数据库服务器很强大。SQL Server 查询分析器是实现此目的的最佳工具。
答案3
即使数据与您的系统相同，如果统计数据已过期，他们的系统也可能会生成不同的查询计划。我会运行EXEC sp_updatestats并查看这是否会有所不同。
答案4
可能是上述任何原因。也可能是网络速度慢（或网络出现问题），因为听起来您正在使用某种 SAN。
客户环境和测试环境中的数据规模是否相同？这是许多开发人员都会犯的一个错误，他们用一组数据来测试性能，而这些数据并没有模拟生产环境中的数据规模。
如果您可以访问 Profiler 和 PerfMon，您可能可以很快缩小问题范围。