MySQL主从复制CPU飙高源于IO_THREAD或SQL_THREAD卡在低效环节：IO线程因网络延迟或relay log写入慢导致重试循环；SQL线程因缺失索引引发ROW日志重放时全表扫描；GTID模式下事务校验引发密集哈希查找。
MySQL主从复制本身不直接吃CPU，真正让CPU飙高的，是IO_THREAD或SQL_THREAD卡在某个低效环节里反复空转、重试或密集计算。
IO_THREAD卡在网络或relay log写入慢
主库的Binlog Dump线程持续向从库推日志，一旦网络延迟高、丢包，或从库磁盘写relay log慢（比如IOPS不足、sync_binlog或sync_relay_log设为1），主库线程就会陷入“等待→检测→重试”循环。此时SHOW PROCESSLIST里常看到大量Master has sent all binlog to slave; waiting for more updates，看似空闲，实则CPU单核跑满。
- 确认方式：在从库执行
STOP SLAVE IO_THREAD，观察主库CPU是否明显回落；若回落，问题就在IO链路 - 检查网络：用
tcpdump -i any port 3306抓包，看是否有大量TCP重传 - 查从库状态：
SHOW SLAVE STATUS\G中Seconds_Behind_Master持续增长，但Slave_IO_Running: Yes，说明IO线程“收得慢”，不是连不上
SQL_THREAD重放ROW格式日志时全表扫描
当binlog_format = ROW且从库表缺少关键索引时，SQL_THREAD解析每条UPDATE/DELETE都要做唯一键查找或WHERE条件匹配。如果WHERE id IN (…)字段没索引，一次改几千行就可能触发全表扫描——CPU瞬间拉满，但SHOW PROCESSLIST里看不到对应SQL，因为它根本不在客户端会话里运行。
- 定位方法：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析Exec_Master_Log_Pos附近binlog，看是否有大事务或多行变更 - 必须核对：从库上
WHERE、JOIN、ORDER BY涉及的字段，是否和主库一致建了索引——少一个就可能卡死 - 临时缓解：已发生大事务时，可设
slave_parallel_workers = 0，避免并行模式下锁争用放大CPU压力
GTID模式下SQL_THREAD反复校验事务边界
gtid_mode = ON后，SQL_THREAD每次执行前都得查gtid_executed集合，确认当前事务是否已执行过。如果从库刚重启、或gtid_purged被误清空，它会回溯大量binlog文件做字符串比对和集合查找，CPU集中在memcmp和哈希查找上，SHOW SLAVE STATUS里Seconds_Behind_Master可能为0，但CPU就是下不来。
- 快速判断：执行
SELECT @@gtid_executed;，返回为空或远小于主库的SELECT @@gtid_executed;结果，基本就是GTID状态异常 - 不要盲目
RESET MASTER：这会清空gtid_executed，反而加重校验负担；应先用SELECT * FROM performance_schema.events_statements_summary_by_digest看CPU热点是否集中在GTID相关函数 - 修复前提：确保主库
gtid_purged完整，再在从库执行SET GLOBAL gtid_purged = '…'补全
真正难排查的，是那种SHOW PROCESSLIST里看不到活跃线程、top里MySQL进程CPU高但无法关联到具体SQL的情况——这时候大概率是SQL_THREAD在后台默默做索引查找或GTID比对，而不是你在业务里写的那条UPDATE。
