必须同时设置slave_parallel_type='LOGICAL_CLOCK'和slave_parallel_workers>0才能启用多线程复制，仅设worker数无效；默认DATABASE模式下即使worker设为4也只启1个线程，且依赖主库ROW格式binlog与有效组提交。
必须同时设置 slave_parallel_type 和 slave_parallel_workers，否则从库仍是单线程回放——这是最常踩的坑。
为什么 slave_parallel_workers 设为 4 却只看到 1 个 SQL 线程？
MySQL 5.7 默认 slave_parallel_type = 'DATABASE'，此时即使设了 slave_parallel_workers = 4，也只启用 1 个 worker（因为只有一个数据库）。SHOW PROCESSLIST 里仍只有 1 个状态为 SQL thread 的线程，其余 worker 根本不启动。
- 先执行
STOP SLAVE - 再运行
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK' - 然后设
SET GLOBAL slave_parallel_workers = 4 - 最后
START SLAVE
之后再查 SHOW PROCESSLIST，才能看到多个状态为 Waiting for an event from Coordinator 的 Slave_worker 线程。
LOGICAL_CLOCK 模式下并行效果为何不稳定？
该模式依赖主库的组提交（group commit）——不是你设了参数就能并发，而是主库 binlog 里事务得打包成组，从库才能拆开并行回放。
- 主库
binlog_format必须是ROW或MIXED（STATEMENT下很多语句无法组提交） - 主库开启
sync_binlog = 1会削弱组提交效果；建议设为1000或配合binlog_group_commit_sync_delay = 100 - 避免主库大量
autocommit = 1的小事务；批量写入更易形成可并行的事务组 - 检查主库
SHOW MASTER STATUS和从库Seconds_Behind_Master趋势：若延迟波动大但平均不降，大概率是组提交率低
并发线程数设多少才不翻车？
盲目堆高 slave_parallel_workers 反而拖慢整体速度——worker 过多会争抢 innodb_thread_concurrency、表元数据锁（dict_table_t）、甚至引发频繁上下文切换。
- 从
2开始测试，逐步加到4或8，别直接设成 CPU 核数的 2 倍 - 监控
Threads_running、Innodb_row_lock_waits和磁盘 IO 利用率 - 若
Seconds_Behind_Master不再下降，或出现大量Wait_timeout错误，说明已到瓶颈 - MySQL 8.0+ 默认
slave_parallel_type = 'LOGICAL_CLOCK'，但slave_parallel_workers仍需显式设非零值才生效
真正决定能否跑满多核的，不是参数数字本身，而是主库事务组织方式和从库内部锁竞争情况——配置只是开关，调优得看 performance_schema.replication_applier_status_by_worker 里的实际并行度和阻塞原因。
