MySQL多线程复制通过并行复制机制提升从库应用日志速度，需启用GTID与ROW格式，在主库配置binlog-format=ROW、gtid-mode=ON，在从库设置slave-parallel-type=LOGICAL_CLOCK和slave-parallel-workers>0，重启后使用CHANGE MASTER TO MASTER_AUTO_POSITION=1启动复制，SHOW SLAVE STATUS中Parallel_Mode为LOGICAL_CLOCK表示生效，可显著降低高并发场景下的主从延迟。
MySQL 的多线程复制（Multi-Threaded Replication）可以提升从库应用中继日志的速度，尤其在主库写入压力大、SQL线程成为瓶颈时效果明显。启用该功能主要依赖于 并行复制（Parallel Replication） 机制，从 MySQL 5.7 开始支持，推荐使用 MySQL 8.0 或更高版本以获得更好的稳定性与性能。
1. 确认复制模式为 GTID + 基于事务
多线程复制要求使用基于事务的复制格式，建议开启 GTID 并使用 ROW 格式：
- binlog_format = ROW
- enforce_gtid_consistency = ON
- gtid_mode = ON
在主库的 my.cnf 中配置：
[mysqld] binlog-format=ROW log-bin=mysql-bin server-id=1 gtid-mode=ON enforce-gtid-consistency=ON
2. 配置从库启用多线程复制
在从库上设置以下参数以启用并行回放：
-
slave_parallel_type：决定并行复制的单位。可选值：
- DATABASE：按数据库分发到不同线程（旧方式，限制较多）
- LOGICAL_CLOCK：基于主库组提交（MySQL 5.7+），推荐用于同一数据库内的并发
- slave_parallel_workers：设置 SQL 线程并发数，例如设为 4、8 等（根据 CPU 核心数调整）
- master_info_repository = TABLE
- relay_log_info_repository = TABLE
- relay_log_recovery = ON：确保中继日志崩溃后能恢复一致性
从库 my.cnf 示例：
[mysqld] server-id=2 relay-log=relay-bin relay-log-recovery=ON master-info-repository=TABLE relay-log-info-repository=TABLE binlog-format=ROW gtid-mode=ON enforce-gtid-consistency=ON slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=4
3. 启动复制并验证
重启从库后，执行如下命令启动复制：
CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl', MASTER_PASSWORD='密码', MASTER_AUTO_POSITION=1; START SLAVE;
检查是否启用多线程：
SHOW SLAVE STATUS\G
查看以下字段：
- Slave_IO_Running: Yes
- Slave_SQL_Running: Yes
- Using_Gtid: Yes
- Parallel_Mode: LOGICAL_CLOCK（表示多线程已生效）
- Seconds_Behind_Master 应逐渐下降
4. 注意事项
启用多线程复制后需注意：
- 主库必须开启 GTID 和 ROW 日志，否则无法使用 LOGICAL_CLOCK 模式
- 事务顺序仍受组提交逻辑保护，不会破坏数据一致性
- 如果表之间存在外键或跨库更新频繁，可能影响并行度
- 监控 SHOW PROCESSLIST 中多个 Slave SQL Thread 是否活跃
基本上就这些。只要配置正确，MySQL 多线程复制能显著降低主从延迟，特别是高并发 OLTP 场景下效果明显。
