备库延迟，卡在哪一步？
主从复制、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 之后，效果直接体现在几个方面：
- 备节点并行回放并行度提升，能同时跑的事务更多；
- 调度阻塞链路缩短，协调线程不再成为瓶颈；
- 整体吞吐上升、复制延迟下降，高可用集群的稳定性更有保障。
一句话总结：GreatSQL 8.4.4-5 通过将等待逻辑从协调线程下沉至 worker，实现了并行复制中调度与执行的解耦，从根子上化解了"一个事务卡住、整条链路停摆"的老问题，让备库回放跑得更顺、追得更快。
特性详情见 GreatSQL 8.4.4-5 官方文档：
https://greatsql.cn/docs/8.4.4-5/5-enhance/5-1-highperf-parallel-replica.html