MySQL 多线程复制的优化主要围绕提升从库（replica）并行回放能力，减少主从延迟。自 MySQL 5.7 引入多线程复制（基于库或逻辑时钟），到 MySQL 8.0 的增强支持，合理配置能显著提升复制性能。
启用并配置合适的并行复制模式
MySQL 支持多种并行复制策略，选择适合业务场景的模式是关键。
使用 WRITESET 或 LOGICAL_CLOCK 模式（推荐）：在 MySQL 8.0 中，slave_parallel_type = LOGICAL_CLOCK 结合 slave_parallel_workers > 1 可实现基于事务依赖关系的并行回放，适用于跨库写入且无强顺序依赖的场景。 避免 DATABASE 模式局限性：该模式只允许不同数据库间的并行，若业务集中在单库，无法发挥多线程优势。设置示例：
slave_parallel_type = LOGICAL_CLOCKslave_parallel_workers = 8
slave_preserve_commit_order = ON
调整工作线程数量
worker 数量需结合 CPU 核心数和 IO 能力平衡。
一般建议设置为 CPU 核心数的 1～2 倍，过高可能引发锁争用或上下文切换开销。 监控 Seconds_Behind_Master 和 Replica_queue_size 判断是否需要增加 worker。 通过 SHOW STATUS LIKE 'Slave_%' 查看并行效率。优化事务提交与一致性控制
多线程下保持数据一致性和提交顺序很重要。
开启 slave_preserve_commit_order：确保从库提交顺序与主库 relay log 一致，避免因并行导致的不一致问题。 合理设置 binlog_transaction_dependency_tracking（主库）：影响依赖检测精度，可设为 COMMIT_ORDER、WRITESET 或 WRITESET_SESSION，推荐 WRITESET 提高并发度。减少复制延迟的其他措施
提升 I/O 性能：将 relay log 存放在高速磁盘，避免与其他高负载服务共用存储。 增大 relay_log_recovery 相关参数：确保崩溃恢复后能快速重建复制状态。 避免大事务：大事务会阻塞并行回放，尽量拆分为小事务。 启用 GTID 并配合 MTS：便于故障切换和复制管理。基本上就这些。关键是根据实际负载选择正确的并行策略，调优参数，并持续监控复制状态。不复杂但容易忽略细节。
