SQL Server慢查询排查：等待统计、IO与阻塞监控实战

你有没有遇到过这种局面：业务方一大早冲过来，说系统慢得没法用，你打开任务管理器一看，CPU 才 20%，内存剩了一半，磁盘看起来也没爆，但数据库里的查询就是几秒、几十秒地挂着。这种场面我处理过太多次了。问题往往不在资源“不够”，而在监控的方式——绝大多数新手 DBA 习惯盯着资源百分比，可 SQL Server 性能监控真正要回答的，是“时间都花在哪儿了”。

这篇文章不准备泛泛列指标，而是按照我实际排查性能问题的思路，把 SQL Server 必须监控的核心指标体系拆开讲清楚：从等待统计入手，到 CPU、内存、IO 三条资源线，再到会话阻塞与查询计划回归，最后附一个完整排查复盘。适合刚接手 SQL Server 的运维和 DBA，也适合常年被“慢查询”折磨的开发同学。

另外先提醒一句：很多“慢”其实是连接问题伪装的。比如客户端报 SSL 证书链不可信、无法建立安全连接，表面很像超时、像卡死，但本质是连接配置没搞定。所以第一步务必先通过 SQL Server 错误日志确认是不是连接类故障，再往性能方向查，否则最容易白忙活。

1. 性能监控先分清主次：别被“看着高”的指标带偏节奏

聊点直白的。接手 SQL Server 性能问题，第一步不是看 CPU 是不是 100%，也不是翻磁盘队列长度。真正该做的是回答一个问题：用户提交的请求，时间到底消耗在哪个环节？

SQL Server 本质上是一个处理请求的排队系统。一条查询从提交到结果返回，耗时可以拆成两段：一段是服务时间，也就是真正在 CPU 上执行指令的时间；另一段是等待时间，包括排队等调度、等锁、等 IO 完成、等内存授权等所有“卡着不动”的时间。这个拆解模型是所有性能工作里的地基。想明白这一点，你就不会再被表面指标牵着走——绝大多数“慢查询”的瓶颈根本不是 CPU 算不过来，而是卡在等某个资源。

等待时间在 SQL Server 内部以“等待类型”的形式暴露出来，这也是 wait stats 价值的核心：它直接告诉你数据库究竟在等什么。所以我处理性能问题通常遵循一条固定次序：

1. 先看等待类型，确认整体瓶颈落在 CPU、IO、内存、锁还是网络方向；
2. 再看对应的资源指标，用计数器或 DMV 做交叉验证；
3. 然后定位到具体的会话和查询，找出是谁在消耗、谁在等待；
4. 最后才动手做索引、改语句、调配置。

反过来操作就很容易被误导。我见过同事在 CPU 100% 的时候花一整天调业务索引，最后发现那些 CPU 消耗来自一个定时重建索引的维护任务，正经业务查询只占了一小部分。这就是没按主次来排查走出来的弯路。

1.1 响应时间 = 服务时间 + 等待时间

这条公式我建议直接贴在工位上。数据库性能优化的本质，就是在服务时间和等待时间之间做取舍。

举个例子，一条 SELECT 查询跑了 5 秒。如果服务时间是 4.5 秒，说明 CPU 在执行计划里花了大量时间做运算，这类问题通常和索引缺失、统计信息过期、循环嵌套逻辑低效有关。如果服务时间只有 0.2 秒，剩下 4.8 秒都是等待时间，那就要看它到底在等什么：可能是等锁、等磁盘读、等内存授权。两者的排查方向完全不同，甚至可以说，优化手段正好是反着的。

实际监控时，我习惯先用sys.dm_exec_requests看正在运行的请求状态。一个请求如果长期处于SUSPENDED状态，说明它在等某个资源；如果一直RUNNABLE或RUNNING，则偏 CPU 调度或执行问题。这个一眼就能把方向定下来。

1.2 监控指标的四层视角

把监控体系分成四个层面，是最不容易漏项的做法：

• 实例资源层：CPU、内存、磁盘 IO、网络。
• 数据库等待层：wait stats、锁等待、闩锁等待。
• 会话请求层：当前运行会话、阻塞链、活动事务。
• 查询计划层：执行计划、编译重编译次数、计划缓存命中。

很多监控工具只覆盖第一层和第四层，恰恰中间的等待层与会话层才是定位问题的关键。好比看诊只看体温和血常规，却跳过问诊和影像，自然容易误判。后面几个章节就是围绕这四个层面逐层展开的。

1.3 是否异常的判定标准：基线比阈值更重要

另一个新手最容易踩的坑，是拿着网上搜来的“标准阈值”套一切环境。比如看到 CPU 高于 80% 就报警，看到 Page Life Expectancy 低于 300 秒就慌张。但生产环境之间差异极大：一个 16 核 64GB 的 OLTP 系统和一台 4 核 16GB 的报表服务器，正常负载下的 CPU 分布完全不同；同一套指标在不同业务时段里的表现也可能天差地别。

所以我维护每套实例的“基线画像”：过去 30 天里每小时的平均 CPU、磁盘延迟、主要等待类型占比、活跃会话数。没有基线，所有绝对值都只能用来判断“明显爆了”，很难判断“缓慢劣化”。如果你刚接手一套存量环境，建议先把基线采集跑起来，再谈监控告警，否则第一个深夜报警电话往往是误报打来的。

2. CPU 与计划缓存：从“负载高”定位到“是哪条 SQL 在烧”

CPU 是所有人都爱看的指标，但只盯着 CPU 百分比又是最没价值的监控方式。SQL Server 是多线程应用，真正要看的不是总使用率，而是调度压力和CPU 消耗的归属。

2.1 非抢占式调度与 RUNNABLE 队列

SQL Server 采用类似操作系统的线程调度机制，每个逻辑 CPU 对应一个 scheduler，请求需要进入 runnable 队列才能获得执行机会。当并发请求过多或 CPU 算力不足时，runnable 队列会变长，请求表现为频繁的SOS_SCHEDULER_YIELD等待——线程主动让出 CPU 去排队，等着下一轮调度。

所以判断 CPU 是否出问题，除了看使用率，还要看sys.dm_os_schedulers里runnable_tasks_count是否长期大于 0。如果 runnable 队列持续堆积，即使 CPU 百分比只有 60%，也说明算力已经吃紧；反过来如果队列很干净，就算瞬时 CPU 冲到 90%，通常也只是正常的业务高峰。

2.2 用 DMV 找出 Top CPU 查询

不要靠猜，直接用语句把历史累计的 CPU 消耗大头捞出来：

SELECT TOP 10 s.total_worker_time / 1000 AS total_worker_time_ms, s.execution_count, s.total_worker_time / s.execution_count / 1000 AS avg_worker_time_ms, SUBSTRING(t.text, (s.statement_start_offset / 2) + 1, ((CASE WHEN s.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), t.text)) * 2 ELSE s.statement_end_offset END - s.statement_start_offset) / 2) + 1) AS query_text, s.plan_handle FROM sys.dm_exec_query_stats s CROSS APPLY sys.dm_exec_sql_text(s.sql_handle) t ORDER BY s.total_worker_time DESC;

这条查询的逻辑是：total_worker_time表示该语句在 CPU 上执行的总耗时，execution_count是执行次数，两者一除得到单次平均 CPU 消耗。先将总耗时排序，能快速抓出“累计吃 CPU 最狠”的语句；如果某条语句单次平均消耗很高、执行次数又少，那十有八九是跑偏的执行计划，比那些高频轻量语句更值得优先处理。

2.3 编译与重编译：隐藏的 CPU 杀手

CPU 消耗不只是执行查询，编译计划同样吃 CPU，而且经常被忽略。一条语句如果每一次执行都触发重编译，CPU 消耗可能比执行本身还大。常见的诱因包括：临时表跨批次引用、统计信息在短周期内频繁更新、某些OPTION (RECOMPILE)滥用。

可以用这个 DMV 观察编译相关的信号：

SELECT cntr_value FROM sys.dm_os_performance_counters WHERE object_name LIKE '%SQL Statistics%' AND counter_name = 'SQL Re-Compilations/sec';

重编译频率如果一直居高不下，配合sys.dm_exec_query_stats中plan_generation_num异常增大的语句，就可以定位到具体是哪条语句在反复编译。这里有一条经验：不是所有重编译都需要消灭，真正要警惕的是高频、高 CPU 的语句反复编译；对于低频复杂查询，保留RECOMPILE反而合理，因为每次执行换一个更匹配当前参数的计划，收益大于编译开销。

2.4 并行等待 CXPACKET：别看到它就“治疗”

CXPACKET是并行查询特有的等待类型。过去一提 CXPACKET 就会有人建议关掉并行或降低并行度，这是典型的教条化处理。并行查询里，协调线程等待子线程完成任务，产生一定的 CXPACKET 等待是正常的。只有当它成为占比第一的等待、或者伴随大量 runnable 队列堆积时，才需要考虑对某类语句限制并行度。

与其全局MAXDOP一刀切，我更建议在语句级做OPTION (MAXDOP 2)这类局部限制，或者用 Resource Governor 按工作负载区分处理。把全局并行度调成 1，往往只是把 CPU 压力换成更多的串行等待，性能一点没回来，倒是业务高峰期变得更卡了。

3. 内存与缓存：PLE 不是唯一指标，但它值得每天看

内存监控里名气最大的指标是 Page Life Expectancy，也就是数据页在缓冲池里存活的平均秒数。很多监控模板把“大于 300”当正常标准，但这条标准在内存普遍较大的今天其实已经不太够用了。

3.1 缓冲池命中率与 PLE 的局限性

先明确一个概念：SQL Server 会把数据页缓存在内存里，读请求优先走缓冲池，只有缓存未命中时才访问磁盘。Buffer cache hit ratio表示从缓存直接命中的比率，这个值通常都很高，比如 99%。但它有一个致命缺陷：如果 SQL Server 只需要反复读同一批热页，即使总数据量远大于内存，命中率也可以很高，导致你完全忽视真实存在的内存压力。

PLE 的价值是反向信号：它反映的是“一个数据页在缓冲池中多久没被淘汰”。PLE 越低，说明页淘汰越频繁，缓冲池可能正在被大量冷数据冲击。大内存环境下，8GB 缓冲池的 PLE 300 秒和 256GB 缓冲池的 PLE 300 秒含义完全不同。更科学的做法是看PLE 的变化趋势，而不是死盯绝对值。我见过一台 128GB 内存的机器，PLE 只有 200，但业务很平稳，原因是这台机器服务的是大规模扫描型分析库，缓存页本来就是“用过即走”的模式。

查询 PLE 的脚本：

SELECT cntr_value AS page_life_expectancy_sec FROM sys.dm_os_performance_counters WHERE object_name LIKE '%Buffer Manager%' AND counter_name = 'Page life expectancy';

3.2 从等待类型判断内存压力

比 PLE 更可靠的内存压力信号是等待类型。内存相关等待在sys.dm_os_wait_stats里主要集中在几类：

• PAGEIOLATCH_SH/PAGEIOLATCH_EX：等待数据页从磁盘读入内存。这是“磁盘 IO + 缓存未命中”共同作用的结果，如果 PLE 同时偏低，基本可以断定内存不足导致缓存太小，读请求被迫下探到磁盘。
• RESOURCE_SEMAPHORE：查询等待内存授权，常见于大排序、大哈希联接并发执行时内存不够分。
• RESOURCE_SEMAPHORE_QUERY_COMPILE：等待编译所需的内存。

其中RESOURCE_SEMAPHORE一旦出现，说明某个查询申请的内存超过了可用内存预算，典型的触发场景是多个大型报表同时执行，每个查询都要几十 GB 的排序内存。这个时候加内存是长期方案，短期最见效的手段是限制并发度、优化排序，或者调整查询的内存授予设置。

3.3 查看内存都分给了谁

如果怀疑内存分配异常，直接看内存 Clerk 的分布，判断哪些组件在“吃”内存：

SELECT type, memory_node_id, pages_kb / 1024 AS pages_mb FROM sys.dm_os_memory_clerks ORDER BY pages_kb DESC;

正常情况下，MEMORYCLERK_SQLBUFFERPOOL应该是最大的内存占用方。如果某个非缓冲池组件占用异常高涨，例如MEMORYCLERK_SQLGENERAL或OBJECTSTORE_LOCK_MANAGER长期高企，往往暗示对象缓存堆积或锁管理开销过大，这类问题不是加内存能解决的，得从工作负载本身调整。

3.4 32 位与旧版本环境的提醒

多说一句，如果你还在维护 SQL Server 2008 之类的老版本，或者某些早期 32 位实例，内存地址空间限制会导致 AWE 切换、缓冲池无法充分利用等老问题。这类环境里 PLE 天然偏低，必须更依赖 wait stats 和内存 Clerk 分布来判断，不能照搬现代版本的经验。老版本的问题不在于指标看不懂，而在于指标代表的意义有偏移，需要额外留个心眼。

4. 磁盘延迟与 IO：先分清存储和内存谁在背锅

IO 延迟是 SQL Server 性能问题里最容易被误判的一环。很多人一看到PAGEIOLATCH_SH等待升高就断定“磁盘太慢”，但实际上有一半的情况是内存不足导致缓存命中率下降，IO 请求量被动放大，磁盘只是被连累的。

4.1 文件级 IO 统计：直接看平均延迟

不要只盯计数器里的“Disk Reads/sec”，直接查文件级别的 IO 延迟，数据最客观：

SELECT DB_NAME(database_id) AS db_name, file_id, io_stall_read_ms, num_of_reads, CASE WHEN num_of_reads = 0 THEN 0 ELSE io_stall_read_ms / num_of_reads END AS avg_read_latency_ms, io_stall_write_ms, num_of_writes, CASE WHEN num_of_writes = 0 THEN 0 ELSE io_stall_write_ms / num_of_writes END AS avg_write_latency_ms FROM sys.dm_io_virtual_file_stats(NULL, NULL) ORDER BY avg_read_latency_ms DESC;

io_stall_read_ms是累计的 IO 等待毫秒数，除以num_of_reads得到平均单次读延迟。这个值能从文件粒度告诉你：到底是用户库的数据文件慢，还是日志文件慢，或者是 tempdb 在拖后腿。

4.2 不同存储介质下的延迟参考

不要拿十年前机械盘的阈值去卡今天的 NVMe 阵列，不同介质的延迟水平完全不是一个量级。我常用的经验值如下：

注意，这些数值是 OLTP 场景测出来的经验区间，数据仓库的大规模顺序扫描会有不同的表现。但有一点通用：写延迟对事务系统的影响比读延迟更致命。日志文件如果平均写延迟超过 5ms，事务提交速度会肉眼可见地下降，因为事务必须等日志落盘才能返回成功。

4.3 WRITELOG 等待与事务日志

日志写入是另一个独立监控项。WRITELOG等待类型专门对应“事务提交时等待日志写入磁盘完成”。如果它占比很高，即使数据文件读延迟正常，整体事务吞吐也会被拖死。

处理这类问题有几个方向：先把日志文件和数据文件放到不同的物理存储上，避免读写互相干扰；再看磁盘写缓存是否正常；其次要检查是否存在单个大事务把日志写入路径打满的情况。我曾经遇到一台机器WRITELOG占比 40%，排查到最后是虚拟机的日志磁盘被分配到了和备份存储同一个底层资源池，迁移到独立 SSD 后延迟直接降了一个量级。

4.4 判读 IO 还是内存的交叉验证法

当你同时看到PAGEIOLATCH_SH高和 PLE 低时，先别急着怪存储。用这个逻辑判断：

• 如果 PLE 持续偏低、缓冲池命中率也明显下滑，大概率是内存压力导致读路径放大，优先解决内存问题。
• 如果 PLE 正常、甚至偏高，但PAGEIOLATCH_SH仍然很高，说明确实是存储本身的延迟或吞吐不行。
• 如果只是某个小文件的延迟高，其他文件都正常，则更像文件放置或单盘故障问题，而不是整体资源不足。

先这样把“内存不足引发的 IO”和“存储本身慢”分清楚，再动手优化，能省很多功夫。

5. 等待统计：全局定位瓶颈的最短路径

有了前面的基础，这一节集中讲 wait stats 的判断方法。等待统计在所有监控指标里优先级最高，因为它直接指向“资源瓶颈发生在哪一层”。

5.1 为什么等待统计比资源计数器更可靠

资源计数器描述的是“系统有多忙”，等待统计描述的是“请求有多等”。一条查询把所有 CPU 核都用满，计数器显示 CPU 忙，但请求可能跑得很欢；而大量请求挂在某个锁资源上，CPU 反而是空闲的，计数器会骗你说系统很健康。只有等待统计能把后一种“表面平静、实则卡死”的状态暴露出来。

5.2 聚合等待统计的实用脚本

我们常遇到“等得最久”不等于“影响最大”的问题。比如WAITFOR是无人值守作业里正常的延迟等待，BROKER_RECEIVE_WAITFOR是 Service Broker 空闲时的等待，这些都得排除掉。下面的脚本把常见空闲等待清理掉，然后按占比和平均单次等待时间排序：

SELECT wait_type, waiting_tasks_count, wait_time_ms, wait_time_ms / waiting_tasks_count AS avg_wait_ms_per_task, CAST(100.0 * wait_time_ms / SUM(wait_time_ms) OVER () AS DECIMAL(5,2)) AS wait_percentage FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ( 'WAITFOR', 'WAITFOR_TASK', 'BROKER_RECEIVE_WAITFOR', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'BROKER_EVENTHANDLER', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', 'SQLTRACE_BUFFER_FLUSH', 'SQLTRACE_WAIT_ENTRIES', 'XE_TIMER_EVENT', 'XE_DISPATCHER_WAIT', 'CHECKPOINT_QUEUE', 'LAZYWRITER_SLEEP', 'DIRTY_PAGE_POLL', 'SLEEP_BPOOL_FLUSH', 'SLEEP_SYSTEMTASK', 'LOGMGR_QUEUE', 'MEMSCHEDULER_GROW', 'DBMIRROR_EVENTS_QUEUE', 'DBMIRRORING_CMD', 'HADR_FILESTREAM_IOMGR_IOCOMPLETION', 'HADR_CLUSAPI_CALL' ) ORDER BY wait_time_ms DESC;

实际判断时重点看两列：wait_percentage告诉你是哪个方向的等待占了绝对大头；avg_wait_ms_per_task告诉你单次等待是否剧烈。如果某个等待类型占比 30% 以上，基本就能确定主瓶颈方向。

5.3 常见等待类型速查

ASYNC_NETWORK_IO是个容易被忽略的等待类型。它表面上和网络有关，实际很多情况是客户端程序打开了结果集却没有及时读取，相当于 SQL Server 把结果准备好，却被客户端“晾着”。遇到这个等待，先查应用程序代码，别急着换网卡。

5.4 时间窗口与采样问题

sys.dm_os_wait_stats是实例启动以来的累计值，直接看累计值无法反映近期变化。正确做法是写一个定时任务把快照落表，隔一段时间用差值分析。我习惯创建一张WaitStatsBaseline表，每 15 分钟抓一次快照，然后通过wait_time_ms的增量变化判断分钟内趋势。否则你看到的永远是“从开机到现在”的旧账，新瓶颈会被历史累计值淹没。

6. 会话、阻塞与计划回归：用户感知的“慢”往往在这里

资源层和等待层都看完后，需要回到最实际的层面：当前到底有哪些会话在跑，谁堵住了谁，哪个执行计划最近变差了。

6.1 实时查看阻塞链

最常用的 DMV 是sys.dm_exec_requests。一条查询完状态、等待类型，直出阻塞关系：

SELECT session_id, blocking_session_id, wait_type, wait_time, wait_resource, status, command, DB_NAME(database_id) AS db_name FROM sys.dm_exec_requests WHERE blocking_session_id > 0 ORDER BY blocking_session_id;

如果blocking_session_id不为空，说明这个会话正被另一个会话阻塞。接下来把blocking_session_id再代入这张表，就能一级一级追到阻塞源头。要在生产上快速找到“锁头目”，这是最直接的一步。

6.2 锁等待的常见来源与处理

真实的阻塞来源通常逃不出这几种：长事务不提交、会话持有锁但客户端已经断开连接却不释放（这种最常见，尤其连接池和 ORM 场景）、批量操作缓慢持锁、以及缺失索引导致查询长时间占用共享锁。

看到LCK_M_*等待高，先别急着杀进程。把阻塞链理清，确认阻塞者跑了多久、是不是合法业务。如果确认是僵尸连接，正确做法是终止阻塞会话并修复应用层的连接超时设置，而不是每天手动杀。SQL Server 的lock_timeout、应用侧的Command Timeout以及连接池的Connection Lifetime都该尽早检查。

另一个容易被忽视的阻塞源头是统计信息过期。当统计信息严重过期时，优化器可能选择一个极差的计划，把本来毫秒级的更新操作变成分钟级的大表扫描，进而锁住大量行。所以监控阻塞时，顺手看一下sys.dm_exec_query_stats里该查询的last_execution_time和计划变化，往往能找到比锁更靠前的根因。日常做行转列、组内排序这类轻量查询时，如果基础表统计信息过期，优化器也会选错计划，表现出“网络卡”“程序慢”的假象，其实是查询计划劣化的连锁反应。

6.3 死锁监控：现代首选扩展事件

不要再用 Profiler 抓死锁了，生产环境 Trace 开销大且容易漏事件。推荐用扩展事件，轻量且精准：

CREATE EVENT SESSION [DeadlockMonitor] ON SERVER ADD EVENT sqlserver.database_xml_deadlock_report ADD TARGET package0.event_file ( SET filename = N'C:\XELogs\DeadlockMonitor.xel' ) WITH (MAX_MEMORY = 4096 KB, EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS, MAX_DISPATCH_LATENCY = 10 SECONDS); ALTER EVENT SESSION [DeadlockMonitor] ON SERVER STATE = START;

捕获后用 SSMS 打开 xel 文件，能看到死锁图的 XML，分析两个会话各自持有的锁和等待的资源，死锁的根因通常就是资源访问顺序不一致。修应用逻辑的访问顺序，比任何数据库配置都管用。

6.4 Query Store：捕获计划回退

SQL Server 2016 之后，Query Store 是监控查询计划回归最实用的内置功能。它记录每条查询的历史执行计划、运行时统计，还能强制某个“好计划”。遇到业务反馈“这条 SQL 昨天还很快，今天突然变慢”，优先去 Query Store 里对比前后两个计划的差异，查看是否因为参数值分布变化导致优化器切换到了坏计划。

从 SQL Server 2022 开始，QUERY_STORE的增强甚至可以在出现计划回归时自动进行计划纠正。如果你的实例还没开启 Query Store，建议尽快打开，尤其对业务变更频繁、版本升级在即的环境，这个功能的价值怎么强调都不过分。

7. 一次“CPU 不高但业务卡顿”的排查复盘

讲完指标，用一次真实风格的排查过程把前面所有内容串起来。这套路我用了很多年，基本没有空手而归的时候。

7.1 现象

一套 OLTP 系统，业务方反馈每天下午三点左右出现明显卡顿，交易保存要等好几秒。我打开实例看了一圈：CPU 平均只有 30%，内存占用稳定，磁盘队列也不算长。单看资源计数器，根本找不到嫌疑。

7.2 第一步：等待统计定方向

先取等待统计的差值。结果让我把目光锁定在PAGEIOLATCH_SH上——它的占比从上午的 8% 跳到下午的 35%，同时avg_wait_ms_per_task达到 120ms。这说明大量读请求在等数据页从磁盘读入内存，要么是缓存不够，要么是磁盘确实延迟高。

7.3 第二步：文件级 IO 验证

接着查sys.dm_io_virtual_file_stats，发现某核心业务库的数据文件平均读延迟从基线 2ms 涨到了 20ms 左右。按之前的参考区间，这已经是很明显的延迟劣化。而同盘的其他库延迟依然正常，说明不是整盘故障，更像是这个库的访问模式发生了什么变化。

7.4 第三步：内存与 IO 交叉判断

再看 PLE，下午这个时段从平时的 8000 秒掉到 1200 秒，虽然还是高于网传的 300 秒底线，但趋势很反常。我判断不是单纯内存不足——因为 PLE 只是从“非常健康”跌到“还能接受”，不至于造成 120ms 的读延迟。真正的问题大概率是这个库的读压力大幅上升，或者存储在这一时段受到其他负载干扰。

7.5 第四步：定位到具体查询

回到sys.dm_exec_query_stats，按total_worker_time排序后，发现一条新上线的报表查询成了最大消耗者。它每天都在下午定时执行，扫描一张 5000 万行的日志表做聚合，而且关联字段上缺少索引，执行计划出现大表哈希联接。这道扫描把大量新数据页带入缓冲池，挤掉了原本热门的交易页，于是交易查询的缓存命中率下降，读请求高频落到磁盘上，表现为PAGEIOLATCH_SH集中爆发。

7.6 处理结果

临时方案：把报表查询的调度时间错开交易高峰；根本方案：在关联字段和筛选字段上建联合索引，让聚合能走索引 seek 而非全表扫描。调整之后，PAGEIOLATCH_SH占比在下一个观测周期回落到 7%，交易查询延迟恢复正常。

这次复盘里没有任何一个指标单独指出了真相：CPU 不高、内存看似够用、磁盘总延迟也不算夸张。但把等待统计、文件级 IO、PLE 趋势、Top 查询四层信息拼在一起，问题就非常清晰了。这也是我反复强调“监控必须是闭环”的原因。

写在最后的小经验

这几年排查下来，我越来越觉得 SQL Server 性能监控真正的门槛不在工具，而在“怎么串起来”。单一指标永远是片面的，PLE 高不代表内存没问题，CPU 低也不代表系统很健康。我自己的习惯是：把 wait stats 作为每天上班第一眼要看的数据，配上 CPU、PLE、文件延迟的趋势基线，再辅以 Query Store 和阻塞会话监控，基本就覆盖了日常 90% 的故障类型。

最后再送一段省心技巧：把前文里那几条 DMV 脚本存成存储过程，每天早上自动生成一份“昨日核心指标对比单”，MySQL、Oracle 的经验不一定通用，但 SQL Server 里这一套等待统计 + 基线对比的思路，在任何规模的环境里都是最值得先建立起来的监控能力。