纪环MySQL实例CPU使用率持续飙高，恐怕是DBA和一线后端同学最头疼的告警之一。尤其业务正高峰的时候突然收到一条CPU告警，紧接着各种超时、慢查询报警接踵而来，第一反应往往是想立刻重启实例或者找一条慢SQL直接kill掉。作为一个排查过不少次这类问题的老运维，我今天想把这套从现象定位到根因、再到落地解决的完整思路写下来，希望能给你一个值得参考的清单。
如果你正被“CPU明明很高，但show processlist里一堆SQL都看不出问题”这种状态卡住，或者遇到过“重启完过半小时CPU又拉满”的循环，那这篇文章特别适合你。我会从最开始的系统层观察讲起，沿着“系统→实例→会话→SQL→执行计划→配置参数”这条链路一步步往下拆，最后给出一套可以持续使用的监控和预防方案。
1. CPU飙升时的第一反应：先给实例“把脉”，不要盲目kill或重启
1.1 top命令最容易被误判：CPU高不一定是mysqld的锅
先说一个很多人在慌乱中会犯的错：看到服务器Load Average很高，CPU us久居高不下，就认定是MySQL出了问题。实际上先把 top 看清楚非常关键。
bash复制top -c
top -H -p <mysqld_pid>
第一行看整体负载，第二行看哪个进程占CPU最凶。如果 %CPU 最高的进程不是mysqld，而是别的什么服务，那这事的性质就变了。比如我遇到过几次CPU告警，最后定位到是同一台机器上的数据同步进程在跑全量抽取，或者备份脚本正在压缩归档，还有一次甚至是个采集agent在疯狂扫日志。这些虽然也会导致MySQL响应变慢，但归因完全不一样，解决方向也完全不同。
确认mysqld确实是CPU消耗大户之后，再进MySQL排查。顺便说一句，我自己通常不会立刻kill掉看得到的“慢SQL”，因为没搞清楚因果链就动手，很可能误伤正在跑的核心任务，甚至引发连接池重连风暴。
1.2 进入实例后三步定位：running线程、processlist、语句统计
MySQL侧的第一步不是翻慢日志，而是先看当前实例到底有多少线程正在“实际执行”。很多人会看Threads_connected，但那个数字代表所有连接数，里面一大半可能是空闲连接，参考价值有限。
sql复制SHOW GLOBAL STATUS LIKE 'Threads_running';
Threads_running才是真正在CPU上干活的活跃线程数。如果它持续大于CPU核心数的好几倍，说明SQL已经排队了，CPU就是被这些堆叠的长查询或频繁短查询吃掉的。
第二步是看processlist里每个会话在做什么。线上环境我一般用这句：
sql复制SELECT * FROM sys.session WHERE command = 'Query' AND conn_id <> ps_thread_id();
sys.session比show full processlist好读，能直接看到每个连接跑了多久、在什么状态、当前执行的是什么SQL，而且不会刷屏刷得特别乱。
第三步是看历史语句聚合。如果当前并发看起来不高，但CPU就是高，就需要借助performance_schema把最近一段时间的SQL按“扫描行数”排序找嫌疑人：
sql复制SELECT SCHEMA_NAME, DIGEST_TEXT, COUNT_STAR,
SUM_ROWS_EXAMINED,
SUM_ROWS_SENT,
SUM_TIMER_WAIT / 1e12 AS total_sec
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_ROWS_EXAMINED DESC
LIMIT 20;
用“SUM_ROWS_EXAMINED”而不是“SUM_TIMER_WAIT”排序，是因为CPU消耗和“计算量”更相关，而扫描行数就是计算量的最直接体现。一个SQL哪怕执行时间不长，但如果它每秒被执行几千次、每次扫描几十万行，CPU累计消耗会比某个偶发的半小时慢查询更夸张。
1.3 先判断故障形态：偶发尖峰、持续高位、周期性波动
同一个CPU高，背后的原因可能完全不同，所以有必要在动手前先判断当前属于哪种形态：
| 故障形态 | 特征 | 排查倾向 |
|---|---|---|
| 偶发尖峰 | CPU突然冲到90%以上，几分钟后回落 | 多半是某条大SQL、大事务、后台任务集中触发 |
| 持续高位 | CPU一直高，多条慢SQL并存 | 更可能是查询逻辑、索引设计或连接配置等系统性问题 |
| 周期性波动 | 每天某个固定时段CPU升高 | 多为定时任务、报表、批处理重叠 |
这三种形态决定了排查顺序。偶发尖峰抓当前processlist最有价值；持续高位必须看汇总表和慢日志，单抓一把processlist往往看到的是“每个SQL都在等CPU”的假象；周期性波动则需要结合监控系统按小时切片对比。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 罪魁祸首排行榜第一名：低效SQL让扫描行数远超预期
2.1 大表全表扫描为什么这么耗CPU：逻辑读与重叠判断
很多同学有一个惯性认知：MySQL慢就是IO慢，CPU高跟SQL关系不大。这个印象可能来自很久以前机械硬盘时代的经验，但放到今天的SSD和充足内存环境下，大量SQL其实已经不卡在磁盘IO了，而是卡在InnoDB缓冲池里“反复读取数据页做判断”这件事上。
假设有一张3000万行的订单表，某个查询因为条件没有可用的索引只能走全表扫描。InnoDB需要把数据页从磁盘或Buffer Pool里读出来，再把每一行记录的字段值取出、与WHERE条件比较、逐层返回结果。如果这个过程中数据页能全部放在Buffer Pool里，磁盘IO不高，但CPU全花在了“行比较”上。一个数据页通常能容纳几十行到几百行，哪怕只扫描数据也需要线性的循环解析，扫描行数一旦到千万级别，占用的CPU自然非常可观。
这就是为什么CPU高的时候，我第一个要找的永远是那些“扫描行数极大但返回结果很少”的SQL。它们往往在慢日志里不一定真的很慢，因为单条可能因为命中缓冲池而跑得没那么久，但高频累积下来能让CPU稳稳站在高位。
2.2 慢查询日志里最常出现的三类SQL形态
先说怎么看慢日志。临时开启慢日志在很多场景下是可行的，但要注意别把 long_query_time 设得太低，也别随便打开 log_queries_not_using_indexes，否则大并发下慢日志本身都可能成为拖垮IO的帮凶，反而给排查添乱。
sql复制SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2;
我会在确认现场后临时设置 long_query_time=2 左右，抓一段时间内的慢SQL，再用 mysqldumpslow 做聚合：
bash复制mysqldumpslow -s t -t 30 /var/log/mysql/slow.log
从实际经验看，慢日志里最常出现的CPU消耗型SQL往往具备以下特征之一：
- 大表上无索引条件或索引选择性极差，例如
WHERE status = 1，而status只有两三个取值，优化器一算发现“走索引还不如全表扫”，干脆选了全表。 - 深分页查询，
ORDER BY create_time LIMIT 10000, 20这种写法，前面扫到的上万行都需要参与排序。 - 在索引字段上套了函数或隐式转换，导致字段索引完全失效。
这类SQL有一个通病：它们在设计时觉得“我就查一次，慢点无所谓”，但一旦被接口反复调用，就成了CPU消耗的永动机。
2.3 explain里最该盯住的三个关键指标
定位到疑似SQL之后，不要只是拿时间去衡量，要跑一下执行计划确认扫描规模：
sql复制EXPLAIN SELECT * FROM order_info WHERE status = '1' ORDER BY create_time DESC LIMIT 100;
我一般只看三列：type、rows、filtered。type 如果出现 ALL，代表全表扫描，这是第一优先级要消除的；如果出现 range 或 ref 但 rows 依然是大几十万，也要怀疑索引的区分度不足；filtered 表示存储引擎层返回的数据经过Server层再过滤后的比例，如果 filtered 只有个位数，说明明明在Server层过滤掉了很多行，存储引擎还是把大量行捞了回来，这里面有巨大的浪费。
如果SQL是写操作，还需要用 EXPLAIN UPDATE 或 EXPLAIN DELETE 看它走了什么索引，避免出现“日常不起眼的update把整张表锁住然后全表扫”的低级事故。我之前排过一个案例，就是一个后端同学在更新语句里给关联字段加了字符串拼接函数，导致一条本应只更新几行的语句变成了全表扫描后逐行更新，CPU和锁等待同时在涨，这种问题单看SQL语句很难发现，必须看执行计划。
3. 索引“有但没用上”：失效场景与写放大带来的隐性CPU消耗
3.1 常见索引失效的案例与规避方法
先补充一个容易被忽略的经验：索引不是建了就一定会被使用，尤其是线上数据分布变化之后，优化器可能因为统计信息过时，选择了一个看起来“也能接受”但实际上很差的执行计划。
典型的索引失效我会分成四类：
- 对索引列使用函数。典型例子是
WHERE DATE(create_time) = '2024-01-01'，MySQL在对索引列做函数运算后，索引的有序性就无从谈起了，只能全扫。改成范围写法WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'会好很多。 - 隐式类型转换。比如手机号字段是varchar，查询条件却传了数值
WHERE mobile = 18812345678，MySQL会把字段转成数值类型再比较，索引同样失效。在代码层保持参数类型与字段类型一致，是成本最低的优化手段。 - 前导模糊查询。
LIKE '%keyword%'无法使用普通索引优化，除非搜索引擎或者全文索引介入，否则数据量上来之后这类查询基本是CPU杀手。 - 多列索引违反最左前缀原则，以及范围查询导致右边的字段无法用于过滤。
每一个参数背后，都要去想一想数据页到底做了多少无谓的遍历。
3.2 更新频繁场景下：索引维护本身就是CPU开销
一说CPU高，大家容易把注意力全放到SELECT上，但更新量很大的场景同样会吃CPU。我之前排查过一个库存系统，CPU达到80%以上，慢日志里几乎没有慢查询，后来发现是大量高频短时间内对同一批SKU进行自增自减更新。
原因要从InnoDB索引结构说起。一张有多个二级索引的表，每次UPDATE都会触发二级索引的更新。如果更新的是索引列，那旧索引位置需要标记删除，新索引位置要插入新记录，这过程中可能引发B+树节点的分裂与合并，还要同步维护变更缓冲（change buffer）和对应的重做日志。这些操作全部要消耗CPU，而且如果同一数据页被反复高频更新，页内的维护操作会进一步放大CPU压力。
面对这种热点更新场景，常见手段是降低单点并发，比如把一次UPDATE拆成异步批量更新，或者在应用侧做内存合并后定时落库。应用侧聚合后SQL形态也会从每秒几千次的单条更新，变成一个批量更新范围内的操作，需要强调的是这会增加事务的粒度，因此读多写少的业务需要结合隔离级别进行权衡。一般来说，将热点行的写入频次降到能接受的范围，比一味堆数据库CPU容量要靠谱得多。
3.3 函数索引与冗余字段：什么时候可以信任优化器
MySQL 8.0里面已经有了函数索引，WHERE DATE(create_time) = '2024-01-01' 可以改造成在表达式上建索引，但这属于“对症下药”，不是所有带函数的查询都值得建函数索引。核心判断标准仍然是：执行频率高不高、数据量多大、能不能用更透明的范围条件替代。
如果某个查询场景经常需要同时按多个维度筛选，备选方案还有“冗余字段”这一招。比如订单表里同时存下单时间和订单日期字段，虽然打破了第三范式，但换取的是查询可以直接走普通索引、代码更容易看懂，这类取舍在数据量较大的业务表里是常见设计。
只有当SQL本身已经没什么可优化，执行计划也确实走了正确索引，但CPU还是高时，才需要往更深的“结构性问题”去排查，比如并发连接堆叠、锁等待堆积这些。如果你只盯着单条SQL看，很可能走进死胡同。
4. 连接一多就崩？活跃会话与线程上下文切换带来的CPU放大
4.1 Threads_running和Threads_connected：别把“连得多”当成“跑得多”
我见过一个很有趣的场景：开发同学看到CPU高，抢先查了一下 show variables like 'max_connections'，发现连接数已经接近上限，马上认为是 max_connections 设置太小导致排队，要我调大。但实际操作中我先把 Threads_connected 和 Threads_running 一起看了下，连接虽然有一千多个，真正在跑的却只有十几个。这说明高连接数是结果不是原因，一堆连接卡住后不释放，后续应用不断尝试新建连接，CPU资源被连接建立、鉴权、线程切换大量消耗。
线程切换是很多人忽略的隐性成本。现代CPU一个核在同一时刻只能跑一个线程，如果活跃线程数超过CPU核心数几倍，操作系统就需要频繁切换上下文。每次切换都有额外开销，线程越多切换越频繁，有效工作时间反而在下降。MySQL内部虽然有自己的线程池机制，但默认场景下依然是“一个连接对应一个线程”的重模型，连接数一多切换成本就开始失控。
4.2 锁等待与长事务：线程看似空闲实则在“空转”
还有一类CPU高的幕后推手是锁等待和长事务。比如某个事务持有大量行锁迟迟不提交，其他会话的更新语句全部卡在 Waiting for row lock。从processlist看，每个卡住的连接都在“等待”，但其实它们背后的线程依然活着并被调度器反复检查状态，大量连接同时等待时，同样会放大CPU消耗。
排查这类问题可以查当前持锁比较久的事务：
sql复制SELECT trx_id, trx_state, trx_started,
TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS trx_age_seconds,
trx_mysql_thread_id
FROM information_schema.innodb_trx
ORDER BY trx_started ASC;
更精细的锁等待关系可以看 sys.innodb_lock_waits，它会直接告诉你谁在等谁。找到持锁事务后，要和业务确认能否提交或回滚，长期挂起的异常事务该断就断。
同时也要小心 Waiting for table metadata lock。这个锁最常见的来源是一个会话持有表元数据锁，另一个会话执行DDL被阻塞，后续所有访问这张表的查询全部排队，CPU和连接数双双被拉高。遇到这种状态，优先去 performance_schema.metadata_locks 找到持有者。
4.3 应用连接池和超时配置：解决问题的第一道闸门
数据库侧的排查很重要，但很多CPU高的问题根源不在数据库，而在应用侧把数据库连接池配得太大了。HikariCP这类连接池最大连接数设到100甚至500，再加上服务是多节点部署，数据库瞬间可能要面对上千个连接。每个连接即使空闲也占内存，业务高峰一来全部被唤醒，Threads_running会迅速飙升。
给应用侧的几个具体要求：
- 连接池最大连接数不要盲目设大，通常可以参考服务所在机器可用线程数和下游并发估算，几十个一般已经足够。
- 在JDBC连接串里配置
connectTimeout和socketTimeout，不要让连接无限期挂起。 - 微服务网关或接口层做好熔断限流，一旦数据库压力大，优先保护后端而不是让流量无限灌入。
- 调整
wait_timeout和interactive_timeout，让异常空闲连接尽快被回收，避免大量僵尸连接占满连接数上限。
有些时候我会让开发先重启应用而不是重启数据库，让连接池整体重新初始化，CPU告警常常就能先缓解下来。这和数据“重启后过一会儿又满”并不矛盾，因为如果根因SQL还在，连接池重新放量后依然会打满。
5. 不只是SQL的原因：系统层与InnoDB后台线程的隐形影响
5.1 别让swap和邻居进程干扰判断
CPU高不等于SQL慢，还有一种情况是服务器整体资源本来就紧张。
比如内存不足导致Linux开始使用swap，mysqld占用的内存页被换到磁盘上，访问数据时内核要把页面重新换入内存，这个过程会产生大量页面中断，消耗不少CPU。表现上看mysqld进程CPU也不低，但你抓SQL抓不到任何大查询。这时候需要检查:
bash复制free -h
vmstat 1
如果 si 和 so 两列持续不为0，说明系统在频繁换页。尽量保证实例内存足够。数据库的Buffer Pool命中率极低时，哪怕SQL设计合理也会出现高CPU，因为每一行数据读取都伴随完整的存储和解析过程。
另一个同类问题是邻居进程，比如机器上还跑着数据同步、日志采集、监控Agent。如果遇到CPU告警时系统整体用户态占用高，但mysqld只占其中一小部分，就要把宿主上其他进程一并纳入排查。有些虚拟化平台还会出现同宿主其他实例的资源争抢，这类问题靠MySQL内部手段无解，需要和基础设施团队核对宿主机负载。
5.2 常见参数配置如何间接推高CPU
参数配置对CPU的影响，很多时候是长期的、慢性的，不像SQL问题那样突然爆发。比如：
innodb_buffer_pool_size设置得过小，导致热数据频繁淘汰、频繁从磁盘加载，磁盘IO升高后SQL执行变慢，线程堆积带来CPU切换，最终会呈现CPU偏高。max_connections设置过大，且应用连接池不受控，容易引发线程反复创建销毁。MySQL 8.0里线程数量过多时的管理和调度开销明显高于5.7。sort_buffer_size或join_buffer_size调得过大，虽然单线程排序更快，但连接多时内存暴涨可能触发swap，反而拖累整体性能。innodb_log_file_size设置得太小，重做日志频繁切换，后台落盘线程和checkpoint线程会高频工作，高写入负载下CPU也会被分摊。
这些参数不是看单个就行的，关键要结合实例规格与业务负载形态。我见过一个典型案例：某个实例CPU持续在30%左右波动，数据库侧没有任何慢SQL，后来调大 innodb_buffer_pool_size 后CPU下了一个台阶。磁盘读取的代价虽然主要呈现在IO wait上，但大量等待会导致SQL上下文切换和调度开销。
5.3 MySQL 8.0版本下的后台线程变化
如果你已经在用MySQL 8.0，会比5.7多一点版本相关的排查思路。8.0里InnoDB的后台线程有所调整，比如独立压缩线程、页清理线程、后台脏页刷盘线程的调度方式不同。8.0.30以后redo log还引入了新的并发写机制，高并发写入时它的CPU占用会比旧版本略高。
但这并不意味着要退回5.7，只是排查时需要把“后台线程本身的消耗”纳入考虑。一旦遇到CPU高但SQL侧全部正常的现象，可以把同样规格的实例做一个压测对比，确认是版本原生开销还是配置不当。对大部分业务来说，这条属于最后才会怀疑的冷门路径，不建议一开始就绕进去。
6. 从应急到日常：一套可以落地的监控与治理方案
6.1 平时就能跑的一组“体检SQL”
把排查经验沉淀成一组每天定时跑的SQL，比每次等到告警再现场翻要省力得多。我日常工作台会定期执行这样一组检查：
sql复制-- 1. 当前正在执行的SQL，看看有没有长时间未结束的
SELECT * FROM sys.session WHERE command = 'Query';
-- 2. 每秒实际scan行数较高的会话
SELECT THREAD_ID, ROWS_EXAMINED, ROWS_SENT,
ROWS_EXAMINED / NULLIF(ROWS_SENT, 0) AS exam_sent_ratio
FROM performance_schema.events_statements_current
ORDER BY exam_sent_ratio DESC;
-- 3. 是否存在大量`Waiting for table metadata lock`
SELECT * FROM performance_schema.metadata_locks
WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'PENDING';
第二句把“扫描行数/返回行数”的比值算出来，这个比例如果长期大于几千甚至上万，就说明某些SQL在为极小的结果集做海量扫描，是CPU的典型危险信号。如果这类SQL频率很高，即使单条没进慢日志，也应该纳入专项治理。
为了积累历史趋势，我建议配合 performance_schema.events_statements_summary_by_digest 定期做快照，存到单独的统计库里。比如每天凌晨取一次全量，次日再取一次，两个快照的差值就是当天的语句执行增量数据。这样不用修改数据库参数，也能知道过去24小时里哪些SQL扫描行数涨得最快。
6.2 CPU告警出现后的应急处理顺序
经常有同事问：CPU已经满了我到底先做什么？其实无外乎下面几个动作，但顺序很关键。
top -c确认mysqld和整体负载，先排除外部进程因素。- 进入MySQL，看
Threads_running，是否高于CPU核数的数倍。 - 查
events_statements_current和sys.session，找出正在跑的、耗时最长或扫描量最大的SQL。 - 对疑似SQL单独跑
EXPLAIN，确认是否走了合理索引。注意禁止在生产高负载时执行需要大量临时空间的排序或复杂分析计划，那是给已经很累的数据库火上浇油。 - 如果确认是某条查询类SQL导致，且该SQL不属于关键路径，可以在应用侧把对应接口的流量切走或降级处理，必要时谨慎kill对应会话。
- 如果发现锁等待或长事务，优先协调业务释放持锁事务。
- CPU回落后再做根治，修改SQL、补索引或调参数。这里特别要提醒：在超大表上直接加索引不是瞬时的，加索引期间可能对写入有元数据锁影响。因此线上加索引要评估表大小和DDL策略，条件允许时先用备库或pt-osc一类的工具演练。
对于“kill”这个动作，我的原则是：能确认目标的慢查询或空闲事务可以杀，但别不分青红皂白把所有查询全干掉。否则应用侧连接池会瞬间建立大量新连接，这个建连过程本身就是一次CPU尖峰，第二波压力可能比第一波更难看。
6.3 月度巡检与索引健康体检
跑通一次紧急排查之后，要把偶然变成日常，就得靠巡检制度了。这个制度不需要很重，我习惯每月做以下几件事：
- 按月对比慢日志量和平均执行时间的趋势，如果慢查询量逐月上升，说明数据量增长或索引设计正在失效。
- 用
sys.schema_unused_indexes找出从未被使用的索引。索引不是越多越好，每个索引都在写入时增加维护成本，删除冗余索引不仅能降低写入CPU，还能减少Buffer Pool占用。 - 结合历史监控图检查CPU基线的变化。如果CPU平均使用率半年内从20%悄悄涨到50%，不要等接近阈值才动手。
- 对大表执行计划做抽查，尤其是那些超过千万行并且经常出现在高扫描行数排序里的表。
还有一个小习惯是我特别想分享的：不要让“CPU高”成为数据库团队的专属课题，把常见的排查结果和原因沉淀成一张对应关系表，定期同步给后端同学也很有价值。
| 现象特征 | 大概率方向 | 优先动作 |
|---|---|---|
| Threads_running高 + 瞬时尖峰 | 大查询/突发任务 | 抓events_statements_current |
| Threads_running高 + 持续不断 | 慢SQL堆积或索引失效 | 查看digest汇总表 |
| Threads_connected高但running低 | 连接未释放、连接池过大 | 查空闲连接、应用连接池 |
| 大量Waiting锁 | 长事务、热点行 | 查innodb_trx、锁等待关系 |
| mysqld不高但整体CPU高 | 外部进程/宿主机资源争抢 | 看top和vmstat |
最后，再聊一个我常用的实操技巧。CPU问题的处理，从来不是“调一个参数就能一劳永逸”的事，而是要把整个链路串起来看。你可以试着把 events_statements_summary_by_digest 的结果留一份每日快照，单独用一条SQL算一下 SUM_ROWS_EXAMINED / SUM_ROWS_SENT 的当日Top值。坚持观察一个月，基本能提前发现那些未来会给CPU带来麻烦的SQL。等CPU告警真的发生时，你手里已经有足够的历史证据，不会陷入“现场抓现行”的被动局面。