并行复制未生效、slave_parallel_type选错或半同步配置不当会导致seconds_behind_master持续不降；需检查slave_sql_running_state和worker_thread状态，并确保log_slave_updates=on及gtid同步正常。
延迟大不是“配了并行复制就自动消失”的问题，而是slave_parallel_workers开了但没生效、slave_parallel_type选错、或半同步配置后主库卡住写入——这三个点踩中任意一个，延迟照样飙到秒级甚至分钟级。
为什么SHOW SLAVE STATUS\G里Seconds_Behind_Master一直不降？
常见错觉是“开了并行就等于多线程在跑”，实际从库可能仍在单线程回放。关键看两个字段：Slave_SQL_Running_State是否为Waiting for an event from Coordinator（说明协调线程空闲），以及Worker_thread是否真有多个活跃线程在执行。
-
slave_parallel_type = 'DATABASE'只对多库架构有效；如果所有表都在同一个库下，哪怕设了 8 个 worker，也只会用 1 个线程 -
slave_parallel_type = 'LOGICAL_CLOCK'依赖主库的组提交，若主库binlog_group_commit_sync_delay为 0 或事务太小，组提交失败，从库照样串行 - MySQL 5.7+ 必须同时开启
log_slave_updates = ON，否则 GTID 或并行依赖信息无法传递
semisync_master_wait_point设成AFTER_SYNC还是AFTER_COMMIT？
TP5.1 应用层不做事务控制时，这个参数直接影响写请求响应时间和数据安全性平衡。
-
AFTER_SYNC：主库写完 binlog、等至少一个从库刷盘 relay log 后才返回客户端。延迟感知明显，但崩溃时不会丢事务 -
AFTER_COMMIT：主库先 commit 本地事务，再等从库确认。响应快，但主库 commit 后宕机、从库未收到，该事务就丢了 - TP5.1 默认事务行为是自动 commit，若业务没显式用
Db::startTrans()，建议用AFTER_SYNC保一致性；若压测发现写吞吐掉 30% 以上，再切AFTER_COMMIT并加监控告警
TP5.1 连接从库时如何避开延迟高峰？
框架本身不感知Seconds_Behind_Master，必须自己加路由逻辑。别指望靠“读写分离中间件”自动兜底——很多 TP5.1 项目还在用Db::connect()手动切库。
- 在从库连接前查一次
SHOW SLAVE STATUS，提取Seconds_Behind_Master值，>3 秒就跳过该从库 - 避免在事务内读从库：TP5.1 的
Db::transaction()默认走主库，但若手动调Db::name('xxx')->connect('slave')，事务一致性直接破坏 - 大促前禁用
ALTER TABLE类 DDL：这类操作在从库会锁全表，期间Seconds_Behind_Master飙升且SQL_Thread状态变成Reading event from the relay log而非执行中，监控容易误判
真正卡住延迟的，往往不是配置没开，而是slave_parallel_type和binlog_format不匹配、或半同步插件加载后没重启 IO 线程——这些细节在SHOW SLAVE STATUS里藏得深，但Retrieved_Gtid_Set和Executed_Gtid_Set差值突然变大时，基本就是它了。
