MySQL 8.0+ MTS默认开启但需满足slave_parallel_type=LOGICAL_CLOCK、slave_parallel_workers>0、binlog_transaction_dependency_tracking=WRITESET等条件才生效，否则SQL线程仍单线程回放。
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 结果。
