mysql 5.7多线程复制需同时设置slave_parallel_type='logical_clock'和slave_parallel_workers>0才生效，仅调worker数无效；并行效果依赖主库组提交，且必须重启复制（stop/start slave）才能启用。
MySQL 5.7 的多线程复制能显著降低从库延迟，但默认不生效 —— 必须显式配置 slave_parallel_type 为 LOGICAL_CLOCK，且 slave_parallel_workers > 0，否则仍是单线程 SQL 执行。
为什么 slave_parallel_workers 设为 4 却没看到多个 SQL 线程？
常见错误是只改了 slave_parallel_workers，却没改 slave_parallel_type。MySQL 5.7 默认值是 DATABASE，此时即使 slave_parallel_workers=4，也只会启用 1 个 worker（因为只有一个库）。show processlist 里仍只看到 1 个 SQL thread 状态的线程，其余 worker 不会启动。
必须同时执行：
STOP SLAVE;<br>SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';<br>SET GLOBAL slave_parallel_workers = 4;<br>START SLAVE;
之后再 show processlist，才能看到多个状态为 Waiting for an event from Coordinator 的线程。
LOGICAL_CLOCK 并行依赖主库的组提交，不是所有事务都能并发
该模式的并行能力取决于主库是否真正做了组提交（group commit），这和主库的 binlog_group_commit_sync_delay、sync_binlog 及写入负载有关。如果主库是单条事务频繁提交（如 autocommit=1 且无批量操作），binlog 中事务可能无法形成有效 group，从库也就无法并发回放。
- 确保主库
binlog_format是ROW或MIXED（STATEMENT下部分语句无法组提交） - 避免主库频繁执行小事务；批量写入更利于生成可并行的事务组
- 检查主库
SHOW MASTER STATUS和从库Seconds_Behind_Master趋势：若延迟波动大但平均未降，可能是组提交率低
并发数设多少才合理？别盲目堆高 slave_parallel_workers
设成 CPU 核数的 2 倍未必最优。worker 过多反而引发锁竞争（如 innodb_thread_concurrency 限制、dict_table_t 元数据锁争用），甚至因上下文切换拖慢整体吞吐。
建议按以下顺序调整：
- 先观察从库
SHOW SLAVE STATUS\G中的Slave_SQL_Running_State，确认是否稳定在Waiting for an event from Coordinator - 用
sys.schema_table_statistics或performance_schema.events_statements_summary_by_digest查看是否有长事务阻塞 coordinator 分发 - 从
2开始测试，逐步加到4或8，同时监控Threads_running、Innodb_row_lock_waits和磁盘 IO 利用率 - 若
Seconds_Behind_Master不再下降，或Wait_timeout错误增多，说明并发已到瓶颈，应优先优化单事务性能（如加索引、拆大事务）
最关键的细节常被忽略：修改 slave_parallel_type 后必须 STOP SLAVE; START SLAVE，仅 SET GLOBAL 不会重载 coordinator 逻辑；另外，GTID 模式下配置同样生效，但需确保主库也开启 GTID（否则 LOGICAL_CLOCK 在某些 DDL 场景下可能退化）。
