MySQL 8.0+ 多线程复制（MTS）默认开启但不生效？检查 slave_parallel_type
和 slave_parallel_workers
MySQL 5.7 引入基于
LOGICAL_CLOCK的并行复制，8.0 默认启用，但实际是否并行取决于配置组合。常见现象是
SHOW SLAVE STATUS\G中
Seconds_Behind_Master持续增长，而
Slave_SQL_Running_State显示 “Reading event from the relay log”，说明 SQL 线程仍是单线程回放。
关键参数必须同时满足：
slave_parallel_type = LOGICAL_CLOCK（不能是
DATABASE，后者在库少时几乎无并发）
slave_parallel_workers > 0（建议设为 CPU 核数的 1.5 倍，如 8 核设为 12）
binlog_transaction_dependency_tracking = WRITESET（8.0.26+ 推荐，比
COMMIT_ORDER并发度更高）
transaction_write_set_extraction = XXHASH64（配合
WRITESET使用）
改完需重启复制：
STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 12; START SLAVE;
为什么 WRITESET
能提升 MTS 效率？它依赖主库的写集计算而非事务提交顺序
传统
COMMIT_ORDER只允许“提交时间不重叠”的事务并行，受限于主库压力和网络延迟；
WRITESET则在主库将每个事务修改的主键/唯一键哈希成写集（write set），从库据此判断事务间是否冲突——只要写集无交集，就可安全并行。
但它有硬性前提：
主库必须开启binlog_row_image = FULL（否则无法提取完整写集） 表必须有主键或非空唯一键（否则写集为空，退化为单线程） DDL 语句（如
ALTER TABLE）始终串行执行，会阻塞后续所有事务
验证是否生效：执行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G，观察
WORKERS_PROCESSED是否持续增长；若长期为 0，大概率是表缺失主键。
slave_preserve_commit_order = ON
是双刃剑：保序 vs 吞吐下降
该参数控制从库是否严格按主库提交顺序输出 binlog（影响级联复制和 GTID 连续性）。设为
ON时，即使事务 A、B 可并行，也要等 A 提交完成才允许 B 提交，导致
slave_parallel_workers实际利用率降低。
典型场景权衡：
纯读写分离从库 → 可设为OFF，提升吞吐 作为中间节点参与级联复制 → 必须
ON，否则下游 GTID 乱序报错
Could not execute Write_rows_v1 event on table ... Error_code: 1594使用
WRITESET时，
OFF下并发度更高，但
Seconds_Behind_Master波动可能变大（因提交节奏不均）
调整后监控重点：对比
SHOW SLAVE STATUS中
Exec_Master_Log_Pos增速与主库
SHOW MASTER STATUS的
Position差值，而非只盯延迟秒数。
复制性能瓶颈不在 SQL 线程？先排除 IO 线程和 relay log I/O
很多人一见延迟就调
slave_parallel_workers，但真实瓶颈常在更前端：IO 线程拉取慢、relay log 写盘慢、磁盘 IOPS 不足。表现是
Slave_IO_Running_State长期卡在 “Waiting for master to send event” 或 “Queueing master event to the relay log”。
快速定位步骤：
查 IO 线程状态：SHOW PROCESSLIST找到
system user的
Connect线程，看 State 字段 检查 relay log 所在磁盘：
iostat -x 1观察
%util和
await，若
await > 10ms且
%util == 100%，说明磁盘已饱和 优化 relay log 性能：
relay_log_info_repository = TABLE（避免文件锁）、
sync_relay_log = 10000（减少刷盘次数，但增加崩溃丢失风险）
真正需要调优多线程复制前，确保
Seconds_Behind_Master的增长曲线是平缓上升（SQL 瓶颈），而非阶梯式跳变（IO 瓶颈）。
MTS 的效果高度依赖业务模式：大量小事务、写热点分散、表结构规范时提升明显；反之，单表高频更新或缺失主键，再调参数也难突破单线程天花板。上线前务必用生产流量压测，别只看 sysbench 结果。
