小编Rom*_*kij的帖子

每天我都有一个会话产生 Avg.Disk Queue Length > 800（5 分钟间隔）。

我发现就在这之前 Sql Server 优化器犯了一个错误：它决定使用一个不合适的计划进行聚集索引扫描，这会产生大约 100Mb-1GB 的 IO 操作。假设我找到了排队的原因，但这不是全部。

恕我直言，巨大的 IO 不一定会冻结其他用户 15 分钟。虽然我不知道谁负责创建过多的异步 IO：Sql Server、Windows 文件系统，或者可能是物理 IO 控制器，但是产生的异步 IO 会导致一个巨大的异常队列，并且没有留下任何机会供其他会话从磁盘读取。

有没有办法控制异步IO？我想如果我能够降低队列长度（顺便说一句，“更真实的”当前队列长度计数器显示队列中有 400 个操作），那些查询计划的问题将不会冻结其他会话。

不过情况比较复杂：

这些 sql 查询是从 NAV 4 生成的，所以我在 t-sql 级别上几乎无法更改任何内容。
服务器（Windows 2003 Data Center）是32位的，sql server（数据中心版）使用AWE额外使用8GB做缓冲；因此，AWE 管理器闪存可能会生成这个巨大的队列。
sql server 上最多有 50 个会话。所以我准备好看到 50 个队列长度而不是 800 个！顺便说一句，正常长度是 0.3-4，但这真的很正常，因为我在那里有合适的 RAID。
这个使用 1GB IO 生成查询的疯狂会话还在 sql 优化器出错之前的 40 秒内在同一个表上生成了大约 100000 个“快速”查询。因此，在同一会话中的先前操作期间，索引选择性的变化确实可能以某种方式误导 sql 优化器。

更新：该表一点都不有趣，只是它对于 NAV 来说太大了（1 GB 带索引）。

一些查询的示例：