本文围绕 MySQL CPU 高占用排查指南展开，聚焦“从监控到根因分析的完整流程”的实战方法。通过系统化的监控、初步分析与深度诊断，帮助运维和数据库管理员在遇到高 CPU 情况时，快速定位瓶颈所在并建立可重复的排查路径。
1. 监控与数据收集
1.1 数据源与指标
监控数据源的完整性直接决定排查速度。在排查 MySQL CPU 高占用时，需要同时聚合数据库端指标与操作系统层面的指标，形成跨维度的视图。常见的数据库端指标包括每秒查询数、活动线程数、等待事件、锁等待、慢查询分布等；操作系统层面的指标则关注 CPU 使用率、磁盘 I/O、内存使用和上下文切换等。
核心指标组合应覆盖：CPU 使用率、Active/Sleeping 的线程状态、等待事件分布以及慢查询分布。通过对比瞬时值与历史趋势，可以快速识别异常波动的时间点。
在 MySQL 层，结合慢查询日志、Performance Schema 与全局状态变量，可以把“CPU 高占用”的时空特征描绘得更清晰。
1.2 监控工具与实现
系统层监控工具有助于分辨是否为数据库自身问题还是宿主机资源瓶颈。常见工具包括 top、htop、vmstat、iostat、sar、perf 等，能够提供 CPU、内存、磁盘 I/O 等维度的快照与趋势。
# 示例：快速获取系统CPU和进程CPU占用分布
top -b -n 1 | head -n 20
ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -n 20
数据库端的实时视图能帮助定位热点 SQL 与等待事件，通过 SHOW PROCESSLIST、性能模式视图以及慢日志可以获得关于 CPU 使用的更细粒度信息。
-- 当前连接的简单快照
SHOW PROCESSLIST;-- 按照耗时与等待事件聚焦热点
SELECT * FROM performance_schema Events_Waits_Summary_by_Stage_by Occurrence
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
可视化与告警方面，建议将关键指标接入可视化平台（如 Prometheus + Grafana），设置阈值告警与趋势分析，以便在异常前发出预警。
1.3 指标收集与存储
指标存储要覆盖长期趋势与短期波动，便于事后对比与基线建立。将 MySQL 指标（如 Queries、Connections、Threads_running、Innodb_buffer_pool_read_requests 等）与 OS 指标（如 cpu_user、cpu_sys、iops、read/write latency）统一采集并以时间序列形式持久化。
慢查询与日志的持续积累也不可忽视：开启慢查询日志并设置合理的 long_query_time，确保能够捕捉高 CPU 带来的慢执行。对日志进行滚动归档，避免单点日志过大导致分析困难。
2. 从监控到定位：快速判定CPU瓶颈的初步分析
2.1 初步判断标准
若 CPU 占用持续偏高且伴随响应变慢，需优先判断是否为数据库本身瓶颈，而非网络、磁盘或内存等外部因素。通过对比操作系统的 CPU 使用率与数据库进程的 CPU 消耗分布，可以判定是否为单进程吞吐瓶颈还是多进程竞争导致的全局高占用。
初步分析要点包括：1) CPU 使用是否集中在 mysqld 进程上；2) 是否存在大量等待事件（如锁等待、I/O等待、锁自旋等）；3) 慢查询分布是否与高 CPU 同时出现。
通过对比“瞬时值”与“历史基线”可以快速识别异常点，并为后续的根因分析指明方向。
2.2 快速定位思路
快速定位的核心在于按层次拆解：SQL 层 → 锁与并发层 → I/O 层。首先在 SQL 层寻找高 CPU 的来源（热点 SQL、重复执行、全表扫描等），再转向锁和并发的分析，最后排查是否存在磁盘 I/O 或缓存命中率不足的问题。
实用的快速定位步骤包括：查看当前慢查询与热点语句、分析执行计划、检测锁等待与死锁情况、检查 Innodb 缓冲池命中率与 I/O 延迟。
在实际场景中，CPU 高占用往往是多方因素叠加的结果，因此需要按优先级逐步排查，而不是一次性分析所有指标。
2.3 常见CPU高占用场景
高并发下的慢查询击穿，在峰值请求量下出现大量慢查询，造成处理队列积压与 CPU 持续高负载。
热点语句未使用索引或全表扫描，导致查询时间过长、执行计划频繁切换，进一步推高 CPU 占用。
锁竞争与等待过多，尤其是在高并发写操作场景，锁等待与行级锁争用会显著增加 CPU 的等待时间。
3. 基于诊断数据的根因分析流程
3.1 SQL层排查
在根因分析的第一步，应从 SQL 层开始定位高消耗的语句，通过对比最近执行时间最长、耗时最多的查询，识别潜在的优化点。结合 Performance Schema 的摘要视图，可以看到不同语句对 CPU 的贡献。
常见查询模式及诊断点包括：局部性不佳的 WHERE 条件、缺失索引导致的全表扫描、重复执行的短查询等。
以下为常用示例，用于定位热点语句与其耗时分布：
-- 查找耗时靠前的语句摘要（基于 Digest > 最近统计）
SELECT DIGEST_TEXT, SUM_TIMER_WAIT, COUNT_STAR
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 5;当看到某些语句的 SUM_TIMER_WAIT 值明显偏高时，优先分析其执行计划和索引情况，以确定是否需要重建索引、改写查询或调整 SQL 语句结构。
3.2 执行计划与索引诊断
执行计划是判断高 CPU 的关键证据。通过 EXPLAIN 可以直观看出查询的访问路径、连接顺序、使用的索引以及生产环境中的实际执行情况。
EXPLAIN SELECT /*+ INDEX(t1 idx_user) */ col1, col2
FROM t1
WHERE col3 = ? AND col4 > ?;如果 EXPLAIN 显示全表扫描或未使用有效索引，且相关列缺少索引，此时应评估添加覆盖索引、调整查询条件顺序或改写查询的可能性。
在 MySQL 8 及以上版本，可以使用 EXPLAIN ANALYZE 来获得实际执行计划的执行时间分布，帮助判断是否存在实际执行成本高的环节。
EXPLAIN ANALYZE SELECT col1, col2
FROM t1
WHERE col3 = 'value' AND col4 > 100;
3.3 锁与并发分析
锁和并发往往是高 CPU 的隐形推手。锁等待、死锁、以及长时间持有锁的事务会让 CPU 在等待阶段持续消耗并影响并发吞吐。
通过 Performance Schema 与 InnoDB 的监控视图，可以定位锁等待热点和锁竞争的对象：
SHOW ENGINE INNODB STATUS\G
除了 InnoDB 引擎外，性能架构也提供等待事件的统计，如事件等待总览、按线程分组的等待时间等，可用于定位高 CPU 期间聚焦的等待类别。
SELECT thread_id, event_name, SUM_TIMER_WAIT
FROM performance_schema.events_waits_summary_by_thread_by_event_name
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;
3.4 案例分析与验证
在获得潜在根因后，需要通过对比验证来确认诊断结论。包括在测试环境还原问题、执行对照查询以及回放日志来验证 CPU 变化是否伴随相应的执行路径变化。
验证步骤通常包括：1) 在目标时间窗内重现热点查询；2) 修改特定查询或添加索引后再次观察 CPU 与等待事件的变化；3) 通过基线对照记录确认是否回落至正常水平。
通过系统化的数据对比，可以把根因分析从猜测提升到可重复验证的结论。
