mysql 5.7并行复制未生效主因是slave_parallel_type默认为database，需设为logical_clock；且依赖主库组提交、row格式、无长事务/冲突写集及i/o无瓶颈。
slave_parallel_workers设了但没真并行，是因为slave_parallel_type还是DATABASE
MySQL 5.7默认的slave_parallel_type是DATABASE，不是LOGICAL_CLOCK。这意味着：哪怕你设了slave_parallel_workers = 16，只要主库所有写入都集中在单个库（比如app_db），就只会用1个worker线程干活——其余15个全程闲置。
必须显式切换模式：
STOP SLAVE;SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';START SLAVE;
之后查SHOW VARIABLES LIKE 'slave_parallel_type';确认返回值是LOGICAL_CLOCK，再看SHOW PROCESSLIST;里有没有多个Worker线程状态为Waiting for an event from Coordinator。
主库没产生足够多的last_committed分组，从库worker只能空转
LOGICAL_CLOCK模式依赖主库的组提交（group commit）来生成last_committed和sequence_number。如果主库配置太“激进”，比如：binlog_group_commit_sync_delay = 0且binlog_group_commit_sync_no_delay_count设得极大，事务几乎串行提交，导致大量事务last_committed相同——从库就只能把它们塞进同一个worker串行执行。
检查方法：
- 在主库查
SHOW MASTER STATUS;拿到当前binlog文件名 - 用
mysqlbinlog --verbose解析该文件，搜last_committed字段，看是否大片重复 - 若重复率高，适当调大
binlog_group_commit_sync_delay（比如设为10000微秒）让小事务攒批提交
注意：binlog_format必须是ROW；MIXED或STATEMENT下，含NOW()、UUID()等非确定性函数的事务会强制降级为单线程提交。
从库被长事务/热点行卡住，整个并行队列堵死
LOGICAL_CLOCK并行不是无条件的。一个耗时30秒的大事务（比如全表UPDATE没走索引），会阻塞所有last_committed大于它的后续事务——哪怕它们修改的是完全不相关的表，也得排队等它结束。
更隐蔽的问题是writeset冲突：主库启用binlog_transaction_dependency_tracking = WRITESET后，两个事务若更新同一行（哪怕跨库、跨表），就会被强制串行化。例如：user_db.users和log_db.audit都更新了config_table.id = 1，它们就无法并行。
排查建议：
- 查从库慢日志，找
Rows_examined或Rows_affected异常高的SQL - 拆分批量操作：把
UPDATE ... WHERE id IN (1..10000)改成每50行一批，中间加SLEEP(0.01) - 确认
slave_preserve_commit_order是否意外设为ON（默认OFF），它会强制按主库顺序提交，抵消并行收益
网络或磁盘瓶颈让worker线程根本没活干
如果Slave_SQL_Running_State长期卡在Reading event from the relay log，说明Coordinator线程连中继日志都读不过来——worker再快也没用。常见原因：
- 跨机房同步（如北京⇄广州），RTT 20–50ms，单event拉取+写relay log就上百毫秒
- relay log放在机械盘上，
sync_relay_log = 1又强制每次刷盘 - 主库
max_allowed_packet太小，导致大事务被截断重传
优先验证：Read_Master_Log_Pos和Exec_Master_Log_Pos差值是否持续扩大？如果是，问题不在SQL线程，并行参数调再大也是白搭。此时该换SSD、关sync_relay_log、或者把从库挪到同机房。
slave_parallel_workers，先看performance_schema.replication_applier_status_by_worker里每个worker的实际活跃度——如果只有1–2个在跑，其余全是Waiting，那问题肯定不在“线程数”。
