MySQL 5.7 默认不启用并行复制，因 slave_parallel_workers=0 导致纯单线程回放 relay log，是主从延迟的常见根源；需同时设 slave_parallel_type='LOGICAL_CLOCK' 且 slave_parallel_workers>1，并满足主库 binlog_format=ROW 等前提才真正生效。
MySQL 5.7 默认不启用并行复制，slave_parallel_workers 默认为 0，此时 SQL 线程纯单线程回放 relay log——这是主从延迟长期居高不下的最常见配置根源。
为什么设了 slave_parallel_workers 却没效果
这个参数只是 worker 数量的硬性计数，不是“开关”。它必须和 slave_parallel_type 配合生效：
-
slave_parallel_workers = 0：无 coordinator + worker 架构，纯单线程回放 -
slave_parallel_workers = 1：有 coordinator，但只配 1 个 worker，事务仍串行；实测性能比 = 0 还差约 20% -
slave_parallel_workers > 1：真正启用并行，但前提是slave_parallel_type必须为'LOGICAL_CLOCK'（不能是'DATABASE'）
常见错误现象：SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 始终卡在 “Reading event from the relay log”，且 SELECT * FROM performance_schema.replication_applier_status_by_worker; 只返回 1 行（WORKER_ID = 1），说明并行根本未启动。
slave_parallel_type=LOGICAL_CLOCK 的硬性前提
该模式依赖主库 binlog 中的 last_committed 和 sequence_number 时间戳分组事务，缺一不可：
- 主库
binlog_format必须为ROW（MIXED在某些语句下会退化为STATEMENT，导致依赖信息丢失） - 主库需确保
binlog_order_commits = ON（默认开启，但建议显式确认） - 主库不能用
STATEMENT格式 + 非确定性函数（如NOW()、UUID()），否则事务会被降级为单线程回放 - 从库若配置了
replicate-do-db或Replicate_Wild_Do_Table单库过滤，slave_parallel_type=DATABASE就彻底失效；而LOGICAL_CLOCK不受此限制
必须停库执行的三步操作顺序
截至 2026 年 6 月，slave_parallel_type 仍不支持热更新。跳过任一步，START SLAVE 会失败或静默降级：
- 主库先确认：
SET GLOBAL binlog_format = 'ROW';，并检查binlog_row_image = 'FULL'（推荐） - 从库执行：
STOP SLAVE;→SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';→SET GLOBAL slave_parallel_workers = 4;（建议从 4 起步，不超过 CPU 核心数） - 从库必须同时设置：
SET GLOBAL master_info_repository = 'TABLE'; SET GLOBAL relay_log_info_repository = 'TABLE'; SET GLOBAL relay_log_recovery = ON;，否则元数据冲突会导致并行中断
完成后 START SLAVE;，再查 performance_schema.replication_applier_status_by_worker —— 应看到多行非空记录，且 STATE 为 “Waiting for an event from coordinator” 或 “Executing event”。
长事务会让并行形同虚设
哪怕开了 8 个 worker，只要有一个事务执行超 30 秒，所有后续事务的 last_committed 就无法推进，整个队列被阻塞。这不是配置问题，而是架构限制：
- 在从库执行：
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G，若WORKERS_PROCESSED长期为 0，大概率是协调线程卡在等待一个大事务完成 - 结合
SHOW PROCESSLIST找出对应THREAD_ID正在执行的 SQL，定位源头（比如未分页的批量 DELETE、隐式锁表的 ALTER） -
slave_preserve_commit_order = ON要配合启用，否则乱序提交可能引发主键冲突或一致性风险，尤其在业务未加锁场景下
真正起效的并行复制，从来不是靠堆参数，而是主库组提交质量 + 从库参数协同 + 业务事务粒度控制三者缺一不可。漏掉任意一环，Seconds_Behind_Master 就只是个安慰数字。
