针对你遇到的这个棘手问题——SQL Server突然陷入高磁盘队列长度但吞吐量暴跌的情况，结合我处理过的类似VMware+SAN环境的经验，给你梳理几个可能的排查方向和实操步骤：

一、VMware层面的潜在阻塞点 #

虽然你已经联系过VMware支持，但可以从这些细节入手深挖：

• 检查虚拟机的磁盘适配器配置：确认是否使用了**Paravirtual SCSI(PVSCSI)**适配器（这是SQL Server虚拟机的最优选择），同时查看适配器的队列深度设置。如果队列深度值过低，当SQL Server发起大量并发I/O请求时，会出现队列积压但吞吐量上不去的情况。可以用esxtop工具在ESXi主机上查看DISK面板，对比正常和异常时的QLEN（队列长度）、DAVG（平均延迟）指标，看是否有明显异常。
• 排查存储I/O控制（SIOC）：如果SAN开启了SIOC，检查是否触发了限流阈值。虽然你提到其他文件操作正常，但偶尔其他虚拟机的突发I/O可能导致SIOC限制了SQL Server虚拟机的带宽，不过这种情况概率较低，还是建议确认SIOC的配置和触发日志。
• 快照相关问题：检查SQL Server虚拟机是否存在未删除的快照，尤其是快照链较长的情况。快照会将I/O重定向到快照文件，偶尔会出现I/O阻塞的问题，重启服务器后快照相关的临时资源被释放，问题暂时消失。

二、SQL Server内部的I/O请求异常 #

虽然你初步排除了SQL Server的问题，但还是建议排查这些点：

• 抓取异常时的等待类型：用sys.dm_os_wait_stats或SSMS的活动监视器查看是否有PAGEIOLATCH_*（尤其是PAGEIOLATCH_SH/PAGEIOLATCH_EX）等待持续飙升。这类等待说明SQL Server在等待磁盘I/O响应，但磁盘无法及时处理请求。同时用sys.dm_io_virtual_file_stats查询数据库文件的I/O统计，对比正常和异常时的io_stall_read_ms、io_stall_write_ms，看是否有某个数据文件/日志文件的延迟突然暴涨。
• 排查异常查询或作业：在问题发生时，用sys.dm_exec_requests和sys.dm_exec_query_stats抓取当前运行的请求，看是否有长时间运行的查询、大索引重建作业或统计信息更新任务。有时候看似“正常”的workload可能在特定条件下触发大量随机I/O，导致存储系统出现异常队列。
• 检查并行查询配置：确认SQL Server的max degree of parallelism(MAXDOP)和cost threshold for parallelism设置是否合理。如果并行查询过多，会产生大量并发I/O请求，若存储系统的队列处理能力有限，可能反而导致队列积压但吞吐量上不去。

三、SAN存储的深层配置问题 #

即使更换了硬件，这些配置细节也可能被忽略：

• RAID控制器缓存设置：检查RAID控制器的缓存模式是否为写回(Write-Back)（需搭配电池备份），如果是直写(Write-Through)模式，写性能会大幅下降。另外，查看缓存是否出现临时失效或刷新的情况，这可能导致短时间内I/O性能暴跌。
• LUN队列深度配置：确认SAN的LUN队列深度与VMware虚拟机的磁盘队列深度是否匹配。如果LUN的队列深度设置过低，当SQL Server发起大量I/O请求时，会出现队列阻塞，无法充分利用SSD的吞吐量。
• SSD健康状态：查看SAN中SSD盘的监控数据，检查是否有盘的读写延迟过高、磨损度异常或坏块。即使是新硬件，也可能存在个别盘的兼容性问题，导致整体I/O性能异常。

四、其他容易忽略的点 #

• 备份软件驱动影响：Veeam和LiteSpeed的备份驱动可能在后台残留资源锁，导致I/O阻塞。可以在测试环境中暂时禁用这些驱动，观察问题是否还会出现。
• 病毒扫描干扰：检查是否有病毒扫描软件在后台扫描SQL Server的数据文件或日志文件，不当的扫描策略会严重影响磁盘I/O性能。
• Windows系统过滤驱动：查看Windows设备管理器中的磁盘过滤驱动，确认是否有异常驱动在拦截I/O请求。

备注：内容来源于stack exchange，提问作者Ben Rubin