必须设slave_parallel_type='logical_clock'且slave_parallel_workers>1，否则即使设为16仍是单线程回放；因默认database模式仅跨库才并行，单库下worker闲置，且需主库binlog_format=row、开启组提交、从库slave_preserve_commit_order=1，并停启复制后生效。
直接结论：必须设 slave_parallel_type = 'LOGICAL_CLOCK'，且 slave_parallel_workers > 1，否则哪怕调到 16 也还是单线程回放。
为什么 slave_parallel_workers 设了却没效果？
这不是参数没生效，而是它根本没被触发。MySQL 5.7 默认 slave_parallel_type = 'DATABASE'，这个模式只在主库写入**跨多个库（schema）**时才分发事务。如果所有表都在 order_db 里，那 slave_parallel_workers = 8 的结果是：1 个 worker 在干活，其余 7 个全程 Waiting for an event from Coordinator。
常见误判现象：
-
SHOW SLAVE STATUS\G中Slave_SQL_Running_State一直卡在 “Reading event from the relay log” -
SELECT * FROM performance_schema.replication_applier_status_by_worker;只返回WORKER_ID = 1一行 -
Seconds_Behind_Master持续上涨，但 CPU 和 I/O 并不打满
启用 LOGICAL_CLOCK 前必须确认的三件事
这个模式不是“自动识别依赖”，它靠主库 binlog 里的 last_committed 和 sequence_number 字段分组事务——缺一不可。
- 主库
binlog_format必须为'ROW'：MIXED或STATEMENT下字段不生成，从库收不到分组信息 - 主库需开启组提交：
binlog_group_commit_sync_delay > 0（如 100），且binlog_group_commit_sync_no_delay_count >= 10 - 从库必须设
slave_preserve_commit_order = 1，否则多线程提交顺序错乱，可能引发数据不一致
操作必须停复制，且顺序不能错
slave_parallel_type 在 5.7 不支持热更新，跳过任一步都会静默降级或启动失败。
- 先在从库执行：
STOP SLAVE; - 再依次执行：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';→SET GLOBAL slave_parallel_workers = 4;（建议从 4 起步） - 最后：
START SLAVE; - 注意：
slave_parallel_workers = 1比 = 0 还慢约 20%，因多一层 coordinator 协调开销；= 0 是纯单线程，> 1 才真正启用并行
怎么验证并行复制真正在跑？
不能只看 Seconds_Behind_Master = 0 或线程状态文字，得查底层运行态：
-
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 正在分发任务
最容易被忽略的是：主库没开组提交、binlog_format 不是 ROW、或者从库漏配 slave_preserve_commit_order = 1——这三项任意一项缺失，并行就形同虚设。
