主从同步压垮网卡的主因是binlog流式传输抢占上行带宽，MySQL默认无流控；需用tc限速或启用slave_compressed_protocol、调优binlog_format等真正降带宽措施。
主从同步压垮网卡？先看是不是 binlog 传输在抢带宽
MySQL 主从同步本身不直接限制网络带宽，binlog 文件通过 TCP 流式发送给从库，一旦主库写入压力大、事务多、单条语句更新大量行（比如 UPDATE 全表），就会持续占满上行带宽。这不是配置漏了，而是默认行为——MySQL 不做流控。
常见错误现象：SHOW SLAVE STATUS\G 看起来正常（Seconds_Behind_Master: 0），但主库服务器网卡 tx 持续跑满，其他服务变慢；从库 IO_Running: Yes 但 IO_Queue 延迟波动大。
- 先确认是否真由同步引起：用
iftop -P 3306或ss -i观察主库 3306 端口的发送速率 - 不是所有场景都需要限速——仅当主库和从库跨机房、跨云厂商，或主库本身网络资源紧张时才考虑
-
master_heartbeat_period和带宽无关，它只控制心跳包频率，不能降低流量
真正能限带宽的只有两个办法：网络层 or MySQL 层
MySQL 官方没提供 max_replication_bandwidth 这类参数。想压住流量，得绕道：
- 推荐用
tc（traffic control）在主库系统层限速，比如限制 mysqld 出向流量到 10MB/s：tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms
- 如果必须在 MySQL 内部调，可降低
binlog_row_image（设为MINIMAL）减少日志体积，但需确保从库兼容且业务无误判风险 - 禁用
log_slave_updates（如果从库不作级联中继）也能间接减小主库二进制日志生成量
注意：max_allowed_packet 调小反而可能增加 TCP 包数量，加剧小包开销，不解决带宽问题。
master_heartbeat_period 是干啥的？别被名字骗了
master_heartbeat_period 只控制主库向从库发送空心跳包的时间间隔（单位是秒，实际存储为纳秒），目的是让从库及时发现主库宕机。它不携带数据，不压缩，也不影响 binlog 传输节奏。
- 默认值是 0，即关闭心跳；设为 30 表示每 30 秒发一次空包
- 它只影响
Seconds_Behind_Master的计算精度和故障感知延迟，和带宽占用完全无关 - 设太小（如 1）会增加少量网络包，但对吞吐量无实质影响；设太大（如 300）可能导致从库误判主库失联
- 启用前确认从库 MySQL 版本 ≥ 5.7.8，否则忽略该参数
真正影响同步带宽的三个关键参数
比起乱调心跳，盯住这三个更实在：
-
binlog_format：设为ROW时日志体积最大，MIXED或STATEMENT在部分场景可显著减小日志（但有安全边界，比如非确定函数） -
slave_compressed_protocol=ON：开启后主从之间自动启用 zlib 压缩（MySQL 5.7+），实测对文本类变更压缩率可达 60%–80%，但会略微增加 CPU -
sync_binlog=1和innodb_flush_log_at_trx_commit=1虽然保证安全性，但也导致更多小 IO 和更频繁的 binlog 刷盘，间接放大网络发送频次——如果允许短暂不一致，可权衡设为 0 或 N
压缩和格式选型带来的带宽下降，远比幻想靠 master_heartbeat_period 降速来得实在。多数人卡在这一步，是因为查文档时看到“heartbeat”就以为是“流量心跳”。
