实时时间远高于User与System CPU时间之和，批处理耗时激增排查求助

一、验证是否为I/O瓶颈 #

1. 本地磁盘I/O排查 #

• 用Windows性能监视器（PerfMon）追踪核心指标：
  • 监控PhysicalDisk下的% Disk Time（持续超80%说明磁盘过载）、Avg. Disk Queue Length（数值超过磁盘物理核心数2倍则存在I/O排队）、Avg. Disk Sec/Read/Avg. Disk Sec/Write（读取延迟>20ms、写入延迟>50ms属于异常）
• 任务管理器实时观测：打开「详细信息」页，定位批处理对应进程，对比历史正常时段的「磁盘读取速度」「磁盘写入速度」，确认是否有读写延迟突增
• 检查工作目录磁盘状态：剩余空间不足10%会大幅降低读写性能，同时排查是否存在严重磁盘碎片

2. SQL Server端I/O排查 #

• 执行以下SQL查询，查看VAULT schema相关的I/O等待情况：

SELECT 
  wait_type,
  wait_time_ms,
  signal_wait_time_ms,
  wait_count
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'PAGEIOLATCH_%' -- 页面I/O等待
OR wait_type IN ('WRITELOG', 'IO_COMPLETION') -- 日志写入、I/O完成等待
ORDER BY wait_time_ms DESC;

• 查看查询执行计划：在SSMS中执行目标查询并开启「实际执行计划」，确认是否出现表扫描（原应为索引扫描/查找）、索引失效，或逻辑读/物理读数量大幅上升的情况

二、排查网络问题 #

即使客户反馈网络无变化，仍可通过以下方式验证：

• 连通性与延迟测试：在批处理服务器执行命令，观测是否有丢包或延迟波动：

  ping -t <SQL服务器IP>
  tracert <SQL服务器IP>
  

  若正常延迟<10ms，现突增至100ms+或出现丢包，说明网络存在异常
• 连接状态检查：执行netstat -ano查看批处理进程与SQL Server的连接，是否存在大量TIME_WAIT/CLOSE_WAIT连接，导致新连接建立缓慢
• SQL Server端验证：查询sys.dm_exec_connections，确认来自批处理服务器的连接是否有异常延迟或异常地址记录

三、恢复Fullstimmer统计信息 #

• 检查批处理脚本中Fullstimmer的启用参数，确认是否遗漏输出统计信息的开关（如/stats:on，具体参数依版本而定）
• 排查批处理日志配置，是否存在日志内容限制，导致统计信息被截断或未记录

四、其他排查方向 #

• 服务器负载检查：任务管理器查看CPU、内存使用率，确认是否有其他进程（如备份、杀毒扫描、其他批处理）抢占资源
• SQL Server资源验证：查看sys.dm_os_ring_buffers或SQL Server日志，确认任务执行期间是否存在CPU瓶颈、内存不足导致的页交换
• 查询逻辑校验：即使数据量无变化，仍需确认是否存在隐式类型转换、关联条件变更等导致查询效率下降的情况

内容的提问来源于stack exchange，提问作者Elton Rodrigues