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

我有一个固态硬盘，使用IOmeter测试，显示性能超过200MB / s。但是，当我从本地计算机运行任何SQL查询时，Windows资源监视器从不显示高于7MB /秒的磁盘IO。即使对于耗时超过2分钟的查询，这也适用。瓶颈仅来自SSD的7MB /秒是什么？

我在跑：

Windows Server 2012标准版
SQL Server 2008 R2
英特尔i7 3820
内存32GB
Sandisk SSD

sql-server sql-server-2008-r2 hardware

— 迪恩·麦格雷戈
source

也许数据已经在RAM中并且不需要磁盘访问了？

— gbn

@DeanMacGregor-您如何使用结果？如果在SSMS中尝试尝试丢弃结果该怎么办。这会改变什么吗？另外，您可以尝试在sys.dm_os_waiting_tasks查询运行时查看它是否遇到其他等待类型。

— 马丁·史密斯

随机访问读取是否为200 MB / s（4 KB块的随机读取）？我想这就是数据库通常会做的。查询是否写入磁盘（临时文件，临时结果集或表）？

@DeanMacGregor-因此，可以将其排除在等式之外，您可以将结果分配给标量变量（示例查询）。DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values。因此，不会将任何结果发送回客户端，但计划和IO仍将相同。

— 马丁·史密斯

假设您正在解释ASYNC_NETWORK_IO，是在等待问题是否与网络有关？（通常）不是。正如@MartinSmith所建议的（两次）最有可能的是，SSMS或您使用的应用程序消耗的结果没有SQL提供结果的速度快。按照建议的任何一种方法来省略行的消耗，您将获得最大IO吞吐量的真实图景。

— Mark Storey-Smith

从注释链看来，您正在解释ASYNC_NETWORK_IO等待似乎意味着问题与网络有关。（通常）不是。

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

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

磨练您的其他一些评论：

执行返回900万行的查询时，CPU使用率将保持13％左右，其中sqlserver占9％...如果所有数据都在RAM中，它返回结果的速度是否比3分钟还快？

我们到底在这里测试什么，如何以及为什么？如果您的900万行查询不是a以外的任何其他SELECT * FROM dbo.SomeTable因素，那么除了原始IO吞吐量之外，还有1001个因素在起作用。

您的Intel I7-3820是4核处理器。如果您的测试查询没有生成并行计划，那么如果您从系统中获得超过20％的CPU利用率，我会感到惊讶。

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

我建议：

SELECT *通过SQL Server 仅测试IO。
查询的执行计划的新问题是否要深入探讨为什么它不会使IO饱和。

— 马克·斯托里·史密斯
source

实际上，它只是从dbo.sometable中选择*。抱歉，我没有提过。我的意思是我可以在任何表上运行该查询。我的问题的起源是，即使通过简单的“给我很多数据”查询，我也注意到我的磁盘IO比我预期的要少得多。我的主要担心是，如果根除磁盘IO不足的根本原因，那么如果磁盘IO如此之低可以提高性能。

— Dean MacGregor 2013年