为什么 SQL Server 查询使用的磁盘 I/O 不超过 7MB/秒

Question

我有一个 SSD，使用 IOmeter 测试，显示性能超过 200MB/s。但是，当我从本地机器运行任何 SQL 查询时，Windows 资源监视器永远不会显示超过 7MB/秒的磁盘 IO。即使对于运行时间超过 2 分钟的查询也是如此。瓶颈是什么，它仅使用 SSD 的 7MB/秒？

我在跑：

• Windows Server 2012 标准版
• SQL Server 2008 r2
• 英特尔 i7 3820
• 32GB 内存
• 磁盘固态硬盘

Answer 1

从评论链来看，您似乎将ASYNC_NETWORK_IO等待解释为问题与网络有关。它（通常）不是。

正如@MartinSmith（两次）暗示的那样，最可能的解释是 SSMS 或您正在使用的应用程序没有像 SQL Server 为它们提供服务那样快速地消耗结果。按照任一建议的方法从您的测量中删除行的消耗，您将获得最大 IO 吞吐量的真实（r）图片：

• 执行后丢弃结果
• 将结果分配给标量变量

以防万一，您显然需要DBCC DROPCLEANBUFFERS确保数据实际上是从磁盘而不是缓冲区缓存中读取的。“仅用于测试，不要在活跃的现场环境中执行此操作”等通常的警告适用。

磨练你的其他一些评论：

在执行返回 900 万行的查询时，CPU 使用率将保持在 13% 左右，其中 9% 归因于 sqlserver...如果所有数据都在 RAM 中，它会不会比 3 分钟更快地返回结果？

我们在这里测试的究竟是什么，如何以及为什么？如果您的 900 万行查询不是 aSELECT * FROM dbo.SomeTable则有 1001 个因素起作用，而不仅仅是原始 IO 吞吐量。

您的英特尔 I7-3820是 4 核处理器。如果您的测试查询没有生成并行计划，如果您可以从系统中降低超过 20% 的 CPU 利用率，我会感到惊讶。

返回 900 万行的 3 分钟非常可疑，这表明我们没有全面了解您的测试内容。我的猜测是这是一个次优（非并行）查询计划的情况，里面塞满了拉动数百万行的嵌套循环运算符，即不仅仅是一个表SELECT来验证 IO 消耗。

我建议：

1. SELECT *通过 SQL Server仅测试IO。
2. 如果您想深入了解为什么它不会使 IO 饱和，那么关于您的查询的执行计划的新问题。