MySQL主从延迟越来越大的原因是单线程回放跟不上

从库的Seconds_Behind_Master从几十涨到三千，然后一直挂在那儿。主库写入速度没变，业务侧报的是读到旧数据。重启从库能好十几分钟，之后继续涨。这种走势可以排除网络和账号问题，问题在回放这一侧。

先分清是拉不到还是回放不动。Slave_IO_Running和Slave_SQL_Running两个Yes，说明日志已经拉过来了。Master_Log_File和Read_Master_Log_Pos在动，Relay_Log_Pos不跟，就是回放慢。问题在SQL线程，不在网络上。这两个判断一分钟能做完。

五点六之前的版本，只有一个SQL线程，主库几个并发写，从库排成一队执行。主库并行度越高，这条队排得越长。五点七之后才有按事务分组的并行复制，很多老库一直没升，这一条最省事。排队的另一个原因是主库上偶尔来一个大事务，一个delete删掉上百万行，在主库跑二十秒，在从库要跑四十分钟。这四十分钟里，后面所有的日志都在等。一个事务没有提交，后面的一律不能走。有人以为是磁盘慢，换了SSD，延迟照旧。

更常见的是表没有主键。行复制按主键定位要改的那一行，没有主键就只能全表扫。一张两百万行的表，扫一次几十毫秒，一天几万次更新，就是几千秒。主库上有索引，改一行很快；从库回放时要找那一行，全表扫。

Seconds_Behind_Master这个数本身不可靠。网络断开的时候它显示NULL，大事务执行期间它不动，一提交又瞬间归零。用它判断延迟，经常得出相反的结论。pt-heartbeat的做法是往主库写一条带时间戳的记录，在从库读回来，两个时间相减。这个数才是真实的延迟。装好之后每秒钟一条，曲线画出来，抖在哪儿一目了然。

五点七开始有并行复制，按组提交或者按主键哈希分组。slave_parallel_workers设成八，slave_parallel_type用logical_clock。开了之后仍然不解决问题，多半是主库的并发本来就不高，一组里只有一个事务，并行度上不去。这类场景得回头看大事务和主键。参数改完要重启从库的SQL线程，不是改完就生效。

从库的硬件比主库弱，是最容易忽略的一条。主库十六核，从库四核，同样的回放速度天然差四倍。磁盘IOPS不够的时候，IO线程也会被拖住。这一条在云主机上最常见。

处理顺序按代价排。你先给缺主键的表补上主键，这一步收益最大，风险也最低。再拆大事务，删数据按一万行一批，批间停一秒。然后才是开并行复制，最后考虑升配。顺序反了也能好，但会多花一笔钱。

改完之后盯一周的pt-heartbeat，延迟从三千秒降到个位数。那张没主键的表补上之后，回放速度直接翻了六倍。补主键这步花的时间最短，这条DDL放在低峰跑。