MySQL 5.7 默认不启用多线程复制，因slave_parallel_workers默认为0，此时SQL线程直接单线程回放relay log；设为1反而性能下降约20%，仅当>1且slave_parallel_type=LOGICAL_CLOCK时才真正启用并行。
MySQL 5.7 默认不启用多线程复制，slave_parallel_workers 默认值是 0，SQL 线程始终单线程回放——这是主从延迟居高不下的常见根源。
为什么 slave_parallel_workers = 0 就等于单线程？
这个参数不是“开启/关闭”开关，而是 worker 线程数量的硬性计数：
-
slave_parallel_workers = 0：SQL 线程直接回放 relay log，无 coordinator + worker 架构，纯单线程 -
slave_parallel_workers = 1：coordinator 线程存在，但只配了 1 个 worker，事务仍串行回放；实测性能比= 0还差约 20%，因多了一层协调转发开销 -
slave_parallel_workers > 1：真正启用并行回放，但前提是slave_parallel_type必须设为'LOGICAL_CLOCK'（不能是'DATABASE'）
很多线上环境 SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master 持续上涨，而 Slave_SQL_Running_State 始终卡在 “Reading event from the relay log”，就是这个配置没生效的典型表现。
slave_parallel_type = 'LOGICAL_CLOCK' 是什么前提？
它不是“自动识别事务依赖”，而是依赖 relay log 中记录的逻辑时间戳（last_committed / sequence_number）来分组事务。要让这个机制起效，必须满足：
- 主库 binlog_format 必须为
ROW（MIXED在某些语句下会退化为 STATEMENT，丢失依赖信息） - 主库需开启
binlog_order_commits = ON（默认开启，但显式确认更稳妥） - 从库不能用
DATABASE模式：该模式只按 db 名分发事务，单库业务完全无法并发 - 如果主库是 MySQL 8.0.26+，建议主库额外设
binlog_transaction_dependency_tracking = WRITESET，但 5.7 不支持该参数，只能靠 LOGICAL_CLOCK
执行 SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G，若 WORKERS_PROCESSED 长期为 0，大概率是 slave_parallel_type 没生效或主库日志格式不匹配。
worker 数量设多少才合理？
不是越多越好，关键看从库的 I/O 和 CPU 实际瓶颈：
- CPU 核心数 ≤ 8：设为 4～8；核心数 ≥ 16：可设为 8～12（过高反而引发 mutex 争用和上下文切换损耗）
- relay log 所在磁盘是 SATA SSD 或 HDD：worker 超过 4 后吞吐提升极小，I/O 成瓶颈
- 监控
Replica_queue_size（SHOW SLAVE STATUS 中）：持续 > 1000 表示 relay log 积压严重，可能需要调大slave_parallel_workers或优化主库大事务 - 永久生效必须写入 my.cnf：
slave_parallel_type = LOGICAL_CLOCK和slave_parallel_workers = 8都要加在[mysqld]下，否则重启后还原为默认值 0
注意：master_info_repository 和 relay_log_info_repository 强烈建议设为 TABLE（而非默认 FILE），否则每次写入 master.info/relay-log.info 都是 fsync，实测可带来 50%～80% 的同步吞吐提升。
为什么改完参数还要 STOP SLAVE; START SLAVE;？
MySQL 5.7 的并行复制架构是启动时加载的，运行中修改 slave_parallel_workers 或 slave_parallel_type 不会重建 coordinator 线程池——它们只是变量值变了，旧线程仍在跑。
必须显式停止复制，让 SQL 线程彻底退出，再启动时才会根据新参数初始化 coordinator + N 个 worker 线程。漏掉这步，所有配置都白改。
最容易被忽略的是：5.7 不支持在线热启 coordinator，且 slave_preserve_commit_order 设为 ON 时会强制保序提交，进一步限制并发度——调优时得先关掉它做 baseline 测试，再权衡一致性与吞吐取舍。
