MySQL 5.7需设slave_parallel_workers>1且slave_parallel_type='LOGICAL_CLOCK'才启用真正并行；LOGICAL_CLOCK基于主库binlog的last_committed分组事务，支持单库多表并发，而DATABASE模式仅按库分发，单库场景完全无法并行。
slave_parallel_workers 设为大于 1 且 slave_parallel_type='LOGICAL_CLOCK' 才真正启用并行，这是 MySQL 5.7 比 5.6 及更早版本快的根本前提。
slave_parallel_type='LOGICAL_CLOCK' 是什么，为什么它比 'DATABASE' 有效？
-
'DATABASE'模式下，每个库独占一个 worker 线程，单库多表场景完全无法并发；很多线上实例只有 1 个业务库，此时slave_parallel_workers=4和 =0 效果一样。 -
'LOGICAL_CLOCK'不按库分发，而是依赖主库 binlog 中的last_committed和sequence_number标记事务组——只要事务在主库是组提交（group commit）的，就认为它们无依赖，可并发回放。 - 这意味着哪怕只有一个库、上百张表，只要写入有并发性（如批量 INSERT、多线程应用），从库就能真正并行执行。
常见错误现象：SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master 持续上涨，但 Slave_SQL_Running_State 卡在 “Reading event from the relay log”，说明 coordinator 线程没分发任务给 worker，大概率是 slave_parallel_type 还是 'DATABASE' 或未生效。
主库必须满足哪些条件，LOGICAL_CLOCK 才能起作用？
LOGICAL_CLOCK 不是自动识别依赖，它完全依赖主库日志里有没有正确的逻辑时间戳。以下三点缺一不可：
-
binlog_format=ROW：只有 ROW 格式才能保证每个事务的变更被完整记录，并携带last_committed；MIXED在某些语句下会退化为 STATEMENT，丢失该信息。 -
binlog_order_commits=ON（默认开启，但建议显式确认）：确保组提交顺序与 binlog 写入顺序一致。 - 主库不能是 MySQL 5.5 或更低版本：旧版本不生成
last_committed字段，即使从库设了LOGICAL_CLOCK，也会退化为单线程。
验证方式：
在从库执行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G若
WORKERS_PROCESSED 长期为 0，基本可断定主库日志格式或版本不匹配。
slave_parallel_workers 设多少才合理？
这不是越大越好，worker 数量要匹配从库真实瓶颈：
- 先看 CPU 核心数：一般设为 CPU 核心数的 70%～100%，比如 8 核机器，
slave_parallel_workers=6是较稳妥起点。 - 再看 I/O 能力：如果从库用的是 SATA 盘或低配云盘，盲目设到 16 反而导致大量随机写竞争，延迟反而升高。
- 必须避开
=1：这个值最危险——coordinator 线程存在，但只配 1 个 worker，所有事务仍串行走 worker，还多了一层协调开销，实测性能比=0差约 20%。
典型配置组合：slave_parallel_type='LOGICAL_CLOCK'slave_parallel_workers=4master_info_repository='TABLE'（避免 FILE 模式锁文件带来的同步阻塞）relay_log_info_repository='TABLE'
真正让 MySQL 5.7 多线程复制“快起来”的，从来不是参数本身，而是主库是否输出了可并行的 binlog、从库是否正确解析了这些信息、以及 worker 是否真的被调度执行。很多线上环境调了参数却没效果，问题往往卡在主库 binlog_format 还是 STATEMENT，或者没意识到 slave_parallel_workers=1 是性能陷阱。
