我在客户的生产环境中有一个奇怪的问题。除了 SQL Server 在虚拟服务器上运行之外，我无法提供有关基础架构的任何详细信息。数据、日志和文件流文件在另一台存储服务器上（数据和文件流一起在单独的服务器上登录）。
在我们的本地测试环境中，有一个以这些持续时间执行的特定查询：
- 首先我们清除缓存
- 300ms（第一次需要更长的时间，但从那时起它被缓存了。）
- 20ms
- 15ms
- 17ms
在客户的生产环境中，SQL Server更强大，这些是持续时间（我没有权限清除缓存，明天试试）。
- 2500毫秒
- 2600毫秒
- 2400毫秒
客户生产环境中的服务器功能更强大，但它们确实有虚拟服务器（我们没有）。
可能是什么原因...
- 内存不足？
- 碎片化？
- 物理存储？
您将如何解决这个性能问题？
编辑：
有人问我数据集是否相等，确实如此。我在我们的环境中恢复了他们的数据库。这是真的，这是我看的第一件事。（@Everyone：我添加了编辑，因为这将是许多人首先想到的）。
原因可能是内存不足，碎片，物理存储，以及并行度，争用，不同的表大小，不同的统计信息，不同的SQL补丁级别等设置不同。
所以真的不是关于什么是错的问题，而是如何确定什么是错的问题。我通常的建议是使用Waits and Queues 方法，根据我的经验基本上不是这样或那样。这是一种公平的方法，最终将确定罪魁祸首，然后您将获得解决方案。
可能是内存、CPU、网络或磁盘争用，但是，客户的数据集更大吗？
您的第一步是获取查询本身的执行计划，以确保它不扫描行。你真的应该首先优化查询，因为你已经说过他们的数据库服务器很强大。SQL Server 查询分析器是最好的工具。
即使使用与您的系统相同的数据，如果他们的统计信息过时，他们也很可能会生成不同的查询计划。我会跑
EXEC sp_updatestats，看看这是否会有所作为。我们曾经有一台服务器可以做到这一点。显然，有人将数据库文件设置在 RAID 3 阵列上……这不是一个好主意！
当然，它实际上可以是任何东西，但请确保检查磁盘配置是什么。
它可以是任何这些东西。它也可能是一个慢速网络（或网络上的问题），因为听起来您正在使用某种 SAN。
客户环境与测试环境中的数据规模是否相同？这是许多开发人员犯的一个错误，他们在一组数据上测试性能，而这些数据并没有模拟生产中的数据规模。
如果您可以访问 Profiler 和 PerfMon，您可能可以很快缩小问题范围。
建议的调试方法是检查 SQL Server性能计数器(Start/Run/perfmon.exe)。了解哪些与您的案例相关需要一些时间，但这绝对值得，并有助于准确定位此类问题。
这里有一些对我来说不错的快速链接，谷歌知道的更多：
生产服务器是否与您的测试设置相同？
您提到数据日志和文件系统在存储服务器上，它与什么连接？光纤通道，10/100/1GB？SCSI？光纤通道以外的任何东西都会很慢！！！
存储服务器是否专用于 db 服务器？你在争夺资源吗？
根据所使用的虚拟化技术，虚拟服务器的性能可能会更差，尤其是在磁盘 I/O 方面。在虚拟机上，磁盘访问可以由将虚拟磁盘上的命令转换为物理磁盘上的命令的仿真或驱动程序层来处理。这种模拟通常会引入显着的额外延迟，并且可能无法充分利用底层磁盘阵列。