MySQL主从架构下从库CPU跑满该如何排查与优化-mysql教程-PHP中文网

从库cpu跑满主因是“额外干活”，如被业务误连、重放低效sql时开销放大或并行回放配置失当；应优先查processlist和性能模式定位，而非盲调参数。

mysql主从架构下从库cpu跑满该如何排查与优化

从库CPU跑满，八成不是复制延迟本身导致的，而是从库在“额外干活”——比如被业务直连、重放低效SQL时开销被放大、或并行回放配置失当。直接查 information_schema.processlist 和性能模式比盲调参数更有效。

确认是不是被业务误连了从库

别信“我们没连从库”这种说法。很多团队压根没做网络隔离，应用配置里写的是主库地址，但 DNS 解析或负载均衡策略悄悄把一部分流量导到了从库。

执行 SELECT user, host, db, command, time, state, info FROM information_schema.processlist WHERE command != 'Sleep' AND user NOT IN ('system user', 'replication')
重点看 host 列是否来自业务服务器 IP，info 是否是带 ORDER BY、LIMIT、GROUP BY 的业务查询
临时止血：在从库上执行 SET GLOBAL read_only = ON（不影响复制线程），再配合防火墙封掉业务服务器到从库 3306 端口的非必要访问

检查 SQL Thread 重放阶段的真实 CPU 消耗点

慢查询日志默认不记录 SQL Thread 执行的语句，所以你用 slow_query_log 抓不到问题。得靠性能模式定位重放瓶颈。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

先启用关键消费者：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events%'
查 SQL Thread 的最近事件：SELECT THREAD_ID, EVENT_NAME, TIMER_WAIT FROM performance_schema.events_statements_history_long WHERE THREAD_ID = (SELECT THREAD_ID FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_COMMAND = 'Query' AND PROCESSLIST_INFO LIKE 'insert%') LIMIT 5（注意匹配 PROCESSLIST_INFO 中的典型重放语句）
重点关注 EVENT_NAME 为 statement/sql/select 或 statement/sql/update 且 TIMER_WAIT 异常高的记录

识别重放放大效应：为什么同一条SQL在从库更耗CPU

主库有查询缓存、预编译优化、统计信息更准；从库重放 binlog 时走的是原始文本路径，某些结构天然吃亏。

query_cache_type 主库开、从库关 → 同一条 SELECT 在从库每次都要解析+优化+执行
主库用 PREPARE/EXECUTE，binlog 记的是展开后的文本 → 从库无法复用执行计划，尤其含函数、子查询、未参数化的 WHERE
开启 log_slave_updates 做级联复制 → 同一语句被反复解析，叠加刷盘压力（如 innodb_flush_log_at_trx_commit=1 + sync_binlog=1）
slave_parallel_workers 设太高 → 线程间争抢 mutex、锁表、事务依赖判断开销反超收益

快速验证与收敛手段

别一上来就改全局配置。先做最小干预，看是否能压下 CPU。

临时关闭从库的统计信息自动更新：SET GLOBAL innodb_stats_auto_recalc = OFF（避免重放期间频繁触发采样）
限制并行回放线程数：SET GLOBAL slave_parallel_workers = 2（4核以下机器建议 ≤2，8核可试4）
如果发现大量 Creating sort index 或 Copying to tmp table 状态，说明重放语句本身排序/聚合开销大，需回溯主库源头SQL是否可改写（比如加覆盖索引、拆分大事务）
检查 SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master 是否稳定增长 —— 如果边追边卡顿，大概率是单条重放语句太重，不是并发问题

真正难处理的，是从库重放时因缺失主库上下文（如 session 变量、临时表、函数定义）导致执行路径退化。这类问题不会出现在慢日志里，也很难用 EXPLAIN 复现，必须结合性能模式的 events_statements_summary_by_digest 对比主从的 SUM_TIMER_WAIT 和 SUM_ROWS_EXAMINED 才能揪出来。