MySQL 5.7并行复制无效的根本原因是未满足三组硬性条件：必须同时设slave_parallel_type='LOGICAL_CLOCK'、主库binlog_format=ROW、从库master_info_repository和relay_log_info_repository均为TABLE，且需STOP/START SLAVE重启；仅调大slave_parallel_workers无效。
slave_parallel_workers 设成 8 也没用，根本原因是并行复制压根没启动——MySQL 5.7 默认是单线程回放，必须同时满足三组硬性条件，缺一不可。
为什么 slave_parallel_workers > 0 却没效果？
这个参数不是开关，只是 worker 数量。它只在 slave_parallel_type = 'LOGICAL_CLOCK' 下才真正起作用；设成 'DATABASE' 或保持默认值，哪怕你设了 16，也只会跑 1 个线程。
-
slave_parallel_workers = 0：纯单线程 SQL 线程直接回放 relay log -
slave_parallel_workers = 1：coordinator 存在但只配一个 worker，事务仍串行，实测比 = 0 还慢约 20% -
slave_parallel_workers > 1且slave_parallel_type != 'LOGICAL_CLOCK'：参数被忽略，静默降级为单线程
检查当前模式：SHOW VARIABLES LIKE 'slave_parallel_type';，返回 DATABASE 就踩坑了。
slave_parallel_type = 'LOGICAL_CLOCK' 的生效前提
该模式依赖主库 binlog 中的 last_committed 和 sequence_number 字段分组事务，这两个字段只在特定条件下生成：
- 主库
binlog_format必须为ROW（MIXED在含NOW()、UUID()等非确定函数时会退化为STATEMENT，丢弃组提交信息） - 主库需确认
binlog_order_commits = ON（默认开启，但建议显式执行SET GLOBAL binlog_order_commits = ON;） - 从库必须启用 crash-safe 元数据存储：
SET GLOBAL master_info_repository = 'TABLE';和SET GLOBAL relay_log_info_repository = 'TABLE'; - 从库需设
slave_preserve_commit_order = 1，否则事务提交乱序可能引发数据不一致
注意：slave_parallel_type 不支持热更新，必须停复制后设置。
必须停库执行的三步操作顺序
截至 2026 年 9 月，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;
设完后原 master.info 和 relay-log.info 文件会被删除，元数据转入 mysql.slave_master_info 和 mysql.slave_relay_log_info 表。
验证并行复制是否真正在跑
不能只看 Seconds_Behind_Master = 0 或 Slave_SQL_Running_State 字段，得查底层状态：
-
SHOW PROCESSLIST;里应看到多个system user线程，状态为Waiting for an event from Coordinator -
SELECT * FROM performance_schema.replication_applier_status_by_worker;中WORKER_ID应有多个非NULL的THREAD_ID -
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G;中WORKERS_PROCESSED值持续增长，说明 coordinator 正在分发任务
最容易被忽略的是：即使所有配置都对，只要有一张表缺主键或唯一索引，Error_code: 1032 就会让并行复制立即中断——因为 ROW 格式下，从库靠主键定位行，没主键就只能全表扫描，而并行线程又可能乱序执行，导致“找不着要更新的那行”。
