调大 slave_parallel_workers 反而更卡，是因为未满足并行复制前提：需设 slave_parallel_type='LOGICAL_CLOCK'、主库 binlog_format=ROW 且 binlog_transaction_dependency_tracking=WRITESET，否则仍单线程回放。
调大 slave_parallel_workers 不但不降延迟，反而更卡——这是配置错、依赖没打开、或者根本没满足并行前提导致的。
为什么设了 slave_parallel_workers 还是单线程回放
MySQL 5.7 的并行复制不是“开了就并行”，它默认压根不生效。最常见原因是：slave_parallel_type 还是 DATABASE（5.6 兼容模式），而你的业务只写一个库，比如 orders。这种情况下，哪怕设成 16，也只会用 1 个 worker。
- 必须显式执行：
STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; START SLAVE; - 确认生效：
SHOW VARIABLES LIKE 'slave_parallel_type';返回值得是LOGICAL_CLOCK，不是DATABASE - 再查
SHOW PROCESSLIST：应该看到多个Worker线程（如Worker 1、Worker 2），而不是只有SQL Thread - 如果
Slave_SQL_Running_State长期卡在Reading event from the relay log，说明 IO 或 relay log 读取慢，worker 根本没活干
slave_parallel_workers 设多少才真有用
数值不是越大越好，4～8 是多数 OLTP 场景的合理起点。超过 CPU 核心数后，上下文切换和锁竞争会吃掉收益，甚至拖慢整体吞吐。
- 先看从库负载：
top -H -p $(pgrep mysqld)，观察各线程 CPU 占用是否均匀；如果只有 1–2 个 worker 跑满、其余闲置，瓶颈不在并发度，而在磁盘或 SQL 回放本身（比如大 UPDATE 没索引） - 主库
binlog_format必须是ROW；MIXED或STATEMENT下LOGICAL_CLOCK机制基本失效 - 主库需开启
binlog_transaction_dependency_tracking = WRITESET（MySQL 8.0.19+），否则从库只能退化到粗粒度的COMMIT_ORDER模式 - 从库设
slave_preserve_commit_order = ON会强制等待全局提交顺序，对高并发小事务场景反而抬高延迟；仅当业务强依赖事务可见顺序时才开
跨机房下调 slave_parallel_workers 基本是白忙
北京 ⇄ 广州 RTT 通常 20–50ms，单个 binlog event 拉取 + 写入 relay log 就可能耗时上百毫秒。此时真正卡住的是网络和磁盘，不是 SQL 线程数。
- 优先检查：
Read_Master_Log_Pos和Exec_Master_Log_Pos差值是否持续扩大？如果是，说明 IO 线程追不上，问题在网卡、带宽或主库 binlog 刷盘策略 - 把 relay log 放在低延迟 SSD 上，禁用
sync_relay_log = 1，改用sync_relay_log = 10000减少刷盘次数 - 启用
relay_log_recovery = ON+relay_log_space_limit，避免 relay log 写满导致复制中断 - 用
mysqladmin -h slave_ip extended-status | grep -i "slave.*delay"辅助定位：是Retrieved_Gtid_Set追得慢（网络/IO），还是Executed_Gtid_Set落后（SQL 执行慢）
Seconds_Behind_Master 为 0 不代表没延迟
这个值只反映 relay log 最后一条事件的时间戳和当前系统时间的差，对大事务、并行复制、时钟偏差都极不敏感。它经常“跳变”或“假归零”。
- 主库执行：
SELECT UNIX_TIMESTAMP(); - 从库执行：
SELECT MASTER_POS_WAIT('<code>binlog_file',pos, 0);（用SHOW MASTER STATUS当前位点），返回0才代表完全追平 - 监控必须加维度：
Relay_Log_Space（持续增长=IO 或网络慢）、Slave_SQL_Running_State（长期Waiting for dependent transaction to commit=write-set 依赖太密） - 生产环境强烈建议用
pt-heartbeat，靠心跳表实测端到端延迟，绕过 MySQL 自身指标缺陷
