slave_net_timeout应设为30秒以加快故障发现，配合master_heartbeat_period=15秒防误判；真限速需用tc命令在系统层控制从库出向流量，而非MySQL参数。
MySQL从库复制卡顿，slave_net_timeout设太大会让延迟更难发现
这个参数不是用来限速的，而是控制从库多久没收到主库心跳就判定连接异常。默认值是60秒，设成300甚至3600，看起来“更稳”，实际会让网络抖动或主库假死时，从库傻等很久才重连，延迟悄悄飙到几小时都无感知。
真正影响复制带宽的是网络层和IO线程行为，slave_net_timeout只是故障响应开关。它调小能加快故障发现，但不能压低流量。
- 线上建议设为
30（秒），配合master_heartbeat_period（主库心跳间隔）设为15，避免误判 - 如果主从之间有长链路或不稳定防火墙，不要盲目加大该值，优先查网络丢包、TCP重传
- 修改后需执行
STOP SLAVE; START SLAVE;才生效，仅SET GLOBAL不触发重连
想真限速？用Linux tc命令在从库网卡上做出口限流
MySQL本身不提供复制流量限速功能。唯一靠谱的方式是在从库所在机器的网络栈层面限速，比如用 tc 控制发往主库IP的出向流量（因为从库主动拉binlog，流量方向是从从库发出）。
注意：这不是MySQL配置，而是系统级操作，且只对当前从库生效，不影响其他服务。
- 限速目标通常是控制
CHANGE MASTER TO指定的主库IP，例如主库IP是192.168.10.100，执行：tc qdisc add dev eth0 root handle 1: htb default 12 tc class add dev eth0 parent 1: classid 1:1 htb rate 2mbit tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.10.100/32 flowid 1:1
- 限速值别低于
512kbit，否则IO线程可能频繁超时断连，尤其当binlog event较大时 - 限速后观察
Seconds_Behind_Master是否持续增长，若增长过快，说明带宽已成瓶颈，需调高限速或优化主库binlog写入节奏
复制延迟突增时，先看 SHOW SLAVE STATUS 里的 Seconds_Behind_Master 和 Read_Master_Log_Pos
很多人一看到延迟就去调网络参数，其实80%的情况和带宽无关。真正要盯的是从库IO线程是否还在读、SQL线程是否卡住、relay log有没有堆积。
Seconds_Behind_Master 为 NULL 表示IO线程已断；为0但 Read_Master_Log_Pos 长时间不变，说明IO线程卡在读网络；而 Exec_Master_Log_Pos 不动但 Read_Master_Log_Pos 在涨，才是SQL线程慢。
- 检查
Slave_IO_Running和Slave_SQL_Running必须都是Yes，否则限速毫无意义 -
Relay_Log_Space持续上涨，说明SQL线程处理不过来，可能是大事务、缺少索引、或者从库磁盘IOPS不足 - 不要依赖
Seconds_Behind_Master的绝对值——它在主库空闲时会归零，但真实延迟可能藏在未执行的relay log里
mysqldump + --dump-slave 导出时，slave_net_timeout 会影响锁等待时间
这个场景容易被忽略：用 mysqldump --dump-slave 备份从库时，会先执行 FLUSH TABLES WITH READ LOCK，然后等SQL线程追平relay log再释放锁。如果此时 slave_net_timeout 过大，而主库恰好暂停写入，从库SQL线程会因长时间无新event而休眠，导致锁持有时间远超预期。
- 备份前临时调小该值：
SET GLOBAL slave_net_timeout = 10;，备份完再改回去 - 更稳妥的做法是跳过自动等待，用
--skip-dump-slave+ 手动记录Master_Log_File和Read_Master_Log_Pos - 若从库启用了
relay_log_recovery=ON，备份期间重启会导致relay log重建，--dump-slave可能读不到正确位点，务必提前验证
tc 是唯一直接手段；其余所有MySQL配置，都是在调“反应灵敏度”，不是“油门大小”。 
