为何MySQL主从复制会导致CPU负载过高的情况

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 STATUSG中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。