必须同时设置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 线程。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

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 里的实际并行度和阻塞原因。