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 结果。