mysql 5.7并行复制低效的根本原因是主库binlog缺乏真实可并行的事务分组；即使配置slave_parallel_type=logical_clock且worker>0，若主库binlog_format非row、组提交参数不合理或版本过低，事务仍被归为同一组，导致从库worker空转。
MySQL 5.7 的并行复制不是“设了 slave_parallel_workers 就自动高并发”，它在很多场景下并行度低，根本原因在于：**并行能力取决于主库 binlog 中是否真实存在可并行的事务分组，而不是从库开了多少 worker。**
为什么 slave_parallel_type=LOGICAL_CLOCK 还是串行回放？
看到 Slave_SQL_Running_State 长期卡在 Waiting for an event from Coordinator 或 Reading event from the relay log，说明 worker 线程没活干——不是配置没生效，是主库压根没提供可并行的事务。
- 主库
binlog_format不是ROW：用MIXED或STATEMENT时，含UUID()、NOW()、存储函数等语句会强制退化为单事务提交，破坏组提交连续性 - 主库
binlog_group_commit_sync_delay=0且binlog_group_commit_sync_no_delay_count过大：导致事务几乎逐个提交，last_committed值高度重复，所有事务被分进同一组 - 主库 MySQL 版本 binlog_transaction_dependency_tracking=WRITESET：只能依赖粗粒度的 COMMIT_ORDER 模式，一组内事务少、分组多但每组只有一两个事务
为什么所有表都在一个库，slave_parallel_workers 设再大也没用？
这不是从库的问题，是默认配置陷阱：slave_parallel_type 仍为 DATABASE（5.7 默认值），它只按库名分发事务，单库 = 单 worker，其余 worker 全部挂起等待。
- 必须显式执行：
STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; START SLAVE; - 验证是否生效：
SHOW VARIABLES LIKE 'slave_parallel_type';返回值必须是LOGICAL_CLOCK，不是DATABASE - 再查
performance_schema.replication_applier_status_by_worker，应有多个非空记录；否则说明 coordinator 没把任务分下去
为什么启用了 WRITESET，但仍有大量 Waiting for dependent transaction？
这其实是 writeset 机制在“主动限速”：它检测到事务之间 writeset 冲突率高（比如多个事务都更新 user(id=123)），为避免数据不一致，宁可串行也不乱序执行。
- 典型诱因是主库存在大事务：单个事务更新几百上千行，writeset 哈希碰撞概率飙升，依赖链拉长
- 从库
innodb_flush_log_at_trx_commit=2或0可能掩盖刷盘瓶颈，让 SQL 回放看起来“慢”，实则 I/O 在拖后腿 - 跨机房同步时，网络 RTT 高（如北京⇄广州 40ms+），relay log 拉取和写入本身已成瓶颈，worker 数再多也无事可做
真正影响并行度的，从来不是从库参数调多高，而是主库有没有持续输出带有效 last_committed 分组、低冲突 writeset 的 binlog —— 这一点容易被忽略，但恰恰是调优的起点。
