slave_net_timeout 应设为略大于网络RTT的值，局域网稳定环境建议10~30秒；过大易延迟发现故障，过小则误判主库宕机引发频繁重连与复制中断。
slave_net_timeout 设为多少才合理
默认值 60 秒太保守，多数生产环境会引发误判主库宕机，导致频繁重连、IO线程中断、Seconds_Behind_Master 跳变。实际应根据网络 RTT 和主库写入节奏调整，不是越小越好，也不是越大越稳。
- 局域网稳定环境（RTT 30 是安全起点，兼顾检测速度与抗瞬时抖动能力
- 跨机房或云厂商跨可用区（RTT 20–80ms）：建议
60～90，避免单次网络延迟毛刺触发重连 - 若主库偶发大事务（如批量 delete/update 超过 30 秒无心跳），必须同步调高
slave_net_timeout，否则从库会主动断开连接再重试，造成复制延迟雪球效应
必须配套调整的三个参数
slave_net_timeout 单独改没用，MySQL 复制链路是状态机驱动，底层依赖 TCP 心跳和 MySQL 协议级保活。不配齐关联参数，超时后行为不可控。
-
master_connect_retry：断连后重试间隔，默认 60 秒。若slave_net_timeout=30，建议设为10～15，避免重试太慢拉长恢复时间 -
slave_transaction_retries：仅影响从库回放事务冲突时的重试次数，和网络超时无关，别混淆——它不解决slave_net_timeout触发的问题 -
net_read_timeout和net_write_timeout：这两个是客户端级别超时，对复制线程无效；复制 IO 线程只认slave_net_timeout，改它们没意义
如何验证配置是否生效且没埋雷
改完不能只看 SHOW SLAVE STATUS\G 里 Seconds_Behind_Master 是不是 0，得模拟真实压力场景测反应。
- 用
tcpkill或iptables在从库侧临时丢弃主库 3306 端口的包 35 秒，观察Slave_IO_Running是否变为Connecting，再恢复后能否自动续传 - 查错误日志：
tail -f /var/log/mysql/error.log，确认出现类似error connecting to master 'repl@10.0.1.100:3306' - retry-time: 10 retries: 86400的提示，说明重试逻辑已接管 - 注意一个坑：如果主库启用了
require_secure_transport=ON，而从库连接未走 SSL，slave_net_timeout触发的重连会静默失败，日志只报error connecting，需检查SHOW SLAVE STATUS中Master_SSL_Allowed是否为Yes
为什么有些团队把 slave_net_timeout 设成 10 依然出问题
不是参数本身错，而是忽略了 MySQL 5.7+ 引入的半同步复制（semi-sync）与 slave_net_timeout 的耦合行为。
- 开启
rpl_semi_sync_master_enabled=ON后，主库等待从库 ACK 的逻辑会受slave_net_timeout影响：若从库响应慢，主库可能直接超时退化为异步，但这个过程不记录明显错误，容易误判为“主库性能下降” - 半同步下建议将
slave_net_timeout设为至少2 * rpl_semi_sync_master_timeout（后者默认 10000ms），否则主库还没等够 ACK 时间，就因网络检测超时强行断开从库连接 - 真正稳定的组合是：关闭半同步，或确保
slave_net_timeout ≥ rpl_semi_sync_master_timeout + 5000，并监控Rpl_semi_sync_master_no_times计数器是否持续上涨
网络抖动永远存在，复制稳定性不靠“不超时”，而靠“超时后能正确恢复”。slave_net_timeout 的值只是个开关，背后整条重连、重试、状态同步的链路，才是容易被忽略的复杂点。
