MySQL主从复制延迟飙到几千秒排查是单线程回放扛不住

上周大促压测，监控里从库的 Seconds_Behind_Master 从个位数一路飙到 4000 多秒，主库都已经写完了，从库还在慢吞吞地追。业务侧开始出现"刚下的单查不到"的客诉——读请求走从库，数据还没同步过来。

问题现象

主库写入正常，从库 show slave status 里 Seconds_Behind_Master 持续上涨，能到几千秒不回头；Slave_IO_Running 和 Slave_SQL_Running 都是 Yes，复制线程没断。应用读从库时频繁读到过期数据。重启从库 SQL 线程、等一会儿能追平，但一有大批量写入又立刻落后。

排查过程

先确认复制链路本身没断：

show slave status\G
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 4123
-- Relay_Log_Space: 非常大

IO 线程追得上（binlog 在收），但 SQL 线程回放慢。看从库系统负载，CPU 只有一个核跑满，其余闲着；iostat 磁盘 IO 也没到瓶颈。说明不是资源不够，而是"活儿分配不均"。

再看主库那边同一时间段的写入特征：压测脚本一次性灌了几百万行，而且是一个大事务 INSERT ... SELECT 一次性提交。从库要把这一个事务拆成几百万条来回放，单线程 SQL 线程被这一个事务死死占住，后面的小事务全在后面排队。

根因

MySQL 5.6 以前、以及没开并行复制的配置下，从库只有一个 SQL 线程串行回放 relay log。主库可以多线程并发写，但从库只能一条一条追。一旦主库出现"大事务"或"短时间高并发小事务"，从库的回放速度天然追不上写入速度，Seconds_Behind_Master 就会单向累积。这不是网络慢，也不是磁盘慢，是架构上的单线程瓶颈。

另外大事务本身也是放大器：一个几百万行的事务，从库要把它整个回放完才释放，期间延迟约等于"事务回放耗时"，会瞬间把延迟顶上去。

解决办法

第一，开启并行复制（治本）。 MySQL 5.7+ 用基于逻辑时钟的并行回放：

stop slave;
set global slave_parallel_type='LOGICAL_CLOCK';
set global slave_parallel_workers=8;
start slave;

写进 my.cnf 的 [mysqld] 段持久化。LOGICAL_CLOCK 能保证同一事务内的顺序，又能在不同事务间并行，对大促这类混合写入收益最大。

第二，拆大事务。 把几百万行的批量写入拆成每批一两万的小事务提交，从库能并行消化，延迟不会尖刺式暴涨。

第三，监控加上"回放堆积"维度。 除了看 Seconds_Behind_Master，还要盯 Relay_Log_Space 和从库 SQL 线程的单核 CPU，提前发现回放堆积。

第四，读写分离兜底。 对一致性要求高的读（如下单后查单）强制走主库，避免读到延迟中的从库。

小结

从库延迟九成不是"机器慢"，而是"单线程回放追不上多线程写入"。排障顺序：① show slave status 确认两个线程都是 Yes、延迟单向涨；② 看从库是否只有一个核忙（单线程瓶颈）；③ 查主库同时段是否有大事务/高并发；④ 开 LOGICAL_CLOCK 并行复制 + 拆大事务。并行复制是根因解，大事务拆分是放大器解，两者一起上，延迟基本压得住了。