MySQL并行复制需同时满足slave_parallel_workers>0、slave_parallel_type=LOGICAL_CLOCK、binlog_transaction_dependency_tracking=WRITESET及binlog_row_image=FULL，否则仍串行执行。
为什么 slave_parallel_workers 设了 8 还是串行执行？
MySQL 并行复制不是设了 slave_parallel_workers 就自动加速的，它依赖 slave_parallel_type 的实际生效模式。5.7 默认是 DATABASE，意味着只有跨库写入才能并行；如果所有变更都集中在 orders 库，哪怕设成 16，也只用 1 个线程干活。
-
slave_parallel_type = LOGICAL_CLOCK才能基于事务提交顺序做更细粒度的并行（需开启binlog_transaction_dependency_tracking = WRITESET） - 确认是否启用了
binlog_row_image = FULL——WRITESET依赖完整行镜像，否则降级为COMMIT_ORDER，并行效果打折扣 - 检查
SHOW SLAVE STATUS\G中的Slave_SQL_Running_State：如果长期显示Waiting for dependent transaction to commit，说明依赖检测在卡住，不是 worker 不够
slave_preserve_commit_order = ON 到底要不要开？
这个参数控制从库回放时是否严格保持主库的提交顺序。开它会强制所有 worker 等待全局 commit order，等于给并行加锁——尤其在高并发小事务场景下，延迟反而飙升。
- 仅当业务强依赖从库事务可见顺序（比如依赖
SELECT ... FOR UPDATE跨事务读取最新状态）才必须开 - 绝大多数 Web 应用读的是最终一致性数据，关掉它能让
LOGICAL_CLOCK模式真正跑起来 - 关闭后
Seconds_Behind_Master可能短期跳变（因部分事务提前完成），但整体延迟曲线更平滑、均值更低
如何判断是不是 relay_log I/O 或磁盘拖慢了 SQL 线程？
并行复制的前提是 relay log 能被快速读取和解析。如果从库磁盘慢、或 relay_log_space_limit 频繁触发轮转，SQL 线程会反复等待 IO，worker 再多也白搭。
- 查
SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Read_Master_Log_Pos变化速率：如果位置不动但延迟涨，大概率是 IO 卡在 relay log 写入 - 把
relay_log放到 SSD 分区，并确保sync_relay_log = 10000（而非默认 1），减少刷盘次数 - 避免和
innodb_log_file共用同一块磁盘——日志写入竞争会显著拉低 SQL 线程吞吐
大事务正在把并行复制“堵死”，怎么快速识别和切流？
一个 200MB 的 UPDATE 事务，在 LOGICAL_CLOCK 模式下会阻塞所有后续事务的并行回放，因为它的 writeset 太大、依赖关系无法收敛。
- 用
SELECT * FROM performance_schema.replication_applier_status_by_worker WHERE WORKER_ID != 0\G查哪个 worker 长期STATE = Executing且TASKS = 0 - 结合
SHOW PROCESSLIST找出对应Id的线程，看Info字段是否含长耗时 DML - 紧急时可临时停掉并行：
STOP SLAVE SQL_THREAD; SET GLOBAL slave_parallel_workers = 0; START SLAVE SQL_THREAD;，等大事务过完再调回
真正难处理的不是参数调多少，而是大事务和并行策略的天然冲突——它不看你开了几个 worker，只看你有没有把它拆碎。这点容易被监控图表忽略，得盯住单个 worker 的持续运行时长。
