备库延迟卡在哪一步主从复制、MGR 组复制里备节点靠回放 relaylog 中的 binlog 事务来追平主库。可 binlog 是逻辑日志备节点得把事务重新执行一遍高并发一上来复制延迟就冒头了。现有的并行复制基于 write-set / logical clock 模型用 last_committed 和 sequence_number 两个字段判断哪些事务能并行跑。规则很简单若某事务 last_committed M、sequence_number N 且 M N就得等所有 sequence_number ≤ M 的事务先跑完。问题就出在等这个动作上——传统实现里一旦碰到有依赖关系的事务协调线程coordinator会直接卡住连带后面的 binlog 读取和调度全被堵在门口。前面一个事务没就绪后面一整队都别想动。GreatSQL 的解法让 worker 自己等别拦着后面的车GreatSQL 8.4.4-5 的思路一句话概括把等待从协调线程下沉到 worker 线程调度和执行彻底解耦。具体做了三件事协调线程不再阻塞遇到有依赖的事务协调线程照样往下读、往下派活不再原地干等冲突事务交给 worker 自己等给需要等待的事务打上 need_wait 标记由领到活的 worker 线程执行 wait_for_last_committed_trx自己等自己的前置事务SIGNAL 精准唤醒前置事务一完成通过信号机制唤醒在等待的 worker无缝接着跑。这样一来协调线程始终保持流水线状态不会因为个别事务的依赖关系而整体停摆。怎么开启一个参数搞定优化由参数 replica_parallel_wait_mode 控制WAIT_ON_SQL_THREAD旧行为模式默认值等待逻辑在协调线程WAIT_ON_WORKER_THREAD新行为模式推荐值等待逻辑下沉到 worker。想启用新机制把它调成 WAIT_ON_WORKER_THREAD 即可。收益并行度更高延迟更低把等待逻辑挪到 worker 之后效果直接体现在几个方面备节点并行回放并行度提升能同时跑的事务更多调度阻塞链路缩短协调线程不再成为瓶颈