跨机房MySQL主从复制吞吐低的根本原因是默认超时参数（如slave_net_timeout=60s、net_read_timeout=30s）在高RTT（200ms+）下频繁触发断连重试，导致I/O线程反复重建中继日志；需将slave_net_timeout设为P99 RTT的3～5倍（如300秒），net_read/write_timeout同步调至180以上，并配套调整GTID、并行复制、relay log缓存及binlog压缩等参数成套优化。
跨机房主从复制吞吐量上不去，根本原因不是“配置没调够”，而是默认参数在高延迟（200ms+ RTT）下直接失效：slave_net_timeout 60 秒、net_read_timeout 30 秒，网络一抖就断连重试，I/O 线程反复重建中继日志，吞吐被卡死在几百 TPS。
为什么默认超时参数在跨机房必崩
MySQL 的 I/O 线程不是“持续连接”，它每拉完一批 event 就会进入等待状态；若等待期间超过 net_read_timeout，就会报 ERROR 2013 (HY000): Lost connection to MySQL server during query 并主动断开。跨机房 RTT 波动大，一次 250ms 的延迟抖动，就可能触发超时——而这个值远低于默认的 30 秒，但线程实际卡在 read() 系统调用里，根本等不到 30 秒就已失败。
实操建议：
-
slave_net_timeout必须设为 RTT 最大值 × 3～5 倍，例如专线实测 P99 RTT 为 280ms，建议设为300（单位秒） -
net_read_timeout和net_write_timeout同步调至180以上，避免 I/O 线程在单次读写中途被 kill - 主库侧
wait_timeout和interactive_timeout也需同步加大，否则 Dump 线程连接会被主库主动回收
GTID + 并行复制不是开开关就有效
开了 slave_parallel_type=LOGICAL_CLOCK 却发现延迟照旧？大概率是事务组（transaction group）太稀疏，或者存在长事务阻塞整个 worker 队列。跨机房场景下，大事务（如批量 UPDATE 日志表）一旦进入 relay log，就会让所有并行 worker 等待其提交完成，退化为串行。
实操建议：
- 必须启用
slave_preserve_commit_order=ON，否则并行回放会打乱事务先后依赖，导致主从数据逻辑不一致 - 优先使用
slave_parallel_type=DATABASE，前提是各业务库名完全隔离（如order_db、log_db），能天然分流 - 对吞吐敏感通道，可单独配高并发参数：
CHANGE MASTER TO ... FOR CHANNEL 'order'后执行SET GLOBAL slave_parallel_workers=8（注意：该变量全局生效，但可通过performance_schema.replication_applier_status_by_coordinator观察 per-channel 分布）
relay log 缓存策略决定抗抖能力上限
很多团队以为 relay_log_space_limit=0（不限制）最安全，结果磁盘被撑爆；另一些人设了 1G，却在双通道同步大事务时频繁触发 Waiting for relay log to be written，SQL 线程停摆。
实操建议：
-
relay_log_space_limit推荐设为4294967296（即 4G），既防小事务积压，又避免大事务写满后全链路阻塞 - 务必开启
relay_log_purge=OFF，再配合定时任务跑PURGE RELAY LOGS BEFORE 'yyyy-mm-dd hh:mm:ss'，否则自动清理可能误删未应用日志 - 禁止尝试用
relay_log指定不同路径实现 per-channel 隔离——MySQL 不支持，配置会被忽略
binlog 压缩和组提交是隐藏吞吐放大器
MySQL 8.0+ 的 binlog_transaction_compression=ON 在跨机房场景下收益极明显：实测对含大量文本字段的订单变更，网络传输量减少 60%+，相当于把 200ms RTT 的“有效带宽”翻倍。
实操建议：
- 主库开启
binlog_transaction_compression=ON和binlog_transaction_compression_level_zstd=3（ZSTD 级别 3 是压缩比与 CPU 开销平衡点） - 同时调大
binlog_group_commit_sync_delay=100000（单位微秒，即 100ms），让多个事务的 binlog flush/sync 批量等待，摊薄每次网络 ACK 的 RTT 成本 - 注意：该 delay 值不能大于
slave_net_timeout，否则从库还没收到日志，主库连接先超时断了
真正卡住吞吐的，往往不是某个参数没开，而是多个机制在高延迟下互相咬死：超时短 → 断连重试 → relay log 重建 → 位点丢失 → GTID 冲突 → 全局串行化。调参必须成套动作，且每一步都要验证 SHOW SLAVE STATUS FOR CHANNEL 'xxx' 中的 Seconds_Behind_Master 和 Slave_SQL_Running_State 是否稳定在预期状态。
