多源复制瓶颈源于中继日志空间不足、并行复制全局配置不合理、GTID跨通道冲突及网络带宽争抢，需分通道调优relay_log_space_limit、slave_parallel_type、server_id唯一性及主库带宽。
多源复制中 relay_log_space_limit 设置过低导致 SQL 线程频繁阻塞
多个通道共用同一组中继日志文件，但 relay_log_space_limit 是全局配置项。若设为 1G，而两个通道同时拉取大事务（如批量 UPDATE），中继日志写满后 SQL 线程会停等 I/O 线程清空空间，表现为 Slave_SQL_Running_State 长期卡在 Waiting for relay log to be written。
实操建议：
- 将
relay_log_space_limit调高至 4G～8G（需预留足够磁盘空间），避免跨通道资源争抢 - 禁用
relay_log_purge=OFF时务必配合定期PURGE RELAY LOGS，否则磁盘可能被撑爆 - 不推荐为每个通道单独指定
relay_log文件名——MySQL 不支持 per-channel relay log 路径隔离
并行复制参数未按通道粒度调优
MySQL 8.0+ 的 slave_parallel_workers 和 slave_parallel_type 是全局生效的，但多源场景下各通道负载差异大：比如 channel_a 同步订单库（高频小事务），channel_b 同步日志库（低频大事务）。统一启用 LOGICAL_CLOCK 可能导致 channel_b 的大事务长期独占 worker，拖慢 channel_a 进度。
实操建议：
- 优先设
slave_parallel_type=DATABASE，让不同库的变更天然分发到不同 worker（前提是各主库业务库名不重叠） - 对吞吐压力大的通道，可单独提升其
slave_preserve_commit_order=ON并配slave_parallel_workers=8；低频通道保持默认值即可 - 监控
performance_schema.replication_applier_status_by_coordinator表，观察各 channel 的APPLYING_EVENT分布是否严重倾斜
GTID 模式下跨通道事务冲突引发隐式串行化
启用 GTID 后，MySQL 会强制按 source_uuid:transaction_id 全局排序执行。若 channel_a 和 channel_b 同时同步来自不同主库、但 server_id 冲突（例如都用了 100）的事务，GTID 序列会混杂，SQL 线程只能退化为单线程回放，吞吐量断崖下跌。
实操建议：
- 每个主库必须配置唯一
server_id，且不能与从库自身server_id相同——这是硬性前提，不是建议 - 检查
SHOW SLAVE STATUS FOR CHANNEL 'xxx'中的Retrieved_Gtid_Set是否出现多个uuid交叉增长，若有说明 GTID 源头已污染 - 避免在多源环境中混用 GTID 和非 GTID 主库；一旦启用 GTID，所有主库必须开启
gtid_mode=ON且enforce_gtid_consistency=ON
网络带宽成为多通道并发拉取瓶颈
多个 I/O 线程（每个 channel 一个）同时向不同主库发起 TCP 连接，若主库出口带宽有限或存在 QoS 限速，会出现大量 Seconds_Behind_Master 波动，Slave_IO_Running_State 频繁显示 Connecting to master 或 Queueing master event to the relay log。
实操建议：
- 用
tcpdump -i any port 3306抓包确认各 channel 的流量是否饱和；单主库带宽建议不低于 50MB/s（对应约 400Mbps） - 对延迟敏感的通道，可在主库端配置
max_allowed_packet=256M减少网络往返次数；但需同步调大从库max_allowed_packet - 跨 IDC 场景下，禁用
slave_compressed_protocol=ON——压缩反而增加 CPU 开销，且 MySQL 压缩率有限，不如直接升级带宽
