启用GTID并设置AUTO_POSITION=1后IO线程才自动重连；slave_net_timeout控制读超时而非重连间隔，建议局域网设60、跨机房设30；需将master_info_repository和relay_log_info_repository设为TABLE以加速重连。
MySQL主从闪断后不自动重连？先看CHANGE MASTER TO是否带AUTO_POSITION=1
主从网络短暂中断（比如几秒丢包）后，SHOW SLAVE STATUS\G 显示 Slave_IO_Running: No 且 Last_IO_Error 是 “error connecting to master”，说明IO线程根本没尝试重连——这不是配置问题，是启动方式决定的。
关键点在于：只有启用GTID并显式设置 AUTO_POSITION=1，MySQL才会在连接失败后主动重试；否则默认只连一次，失败就停住。
- 如果用的是传统 binlog 文件+位置方式（
MASTER_LOG_FILE/MASTER_LOG_POS），即使调大超时参数，IO线程也不会自动重连 - 启用GTID后，执行
CHANGE MASTER TO ... AUTO_POSITION = 1，再START SLAVE，后续闪断会触发内置重试逻辑 - 确认是否生效：检查
SHOW SLAVE STATUS\G中的Auto_Position字段值是否为1
slave_net_timeout到底该设多大？别盲目调到30秒
这个参数控制IO线程在读取主库数据时，等待响应的最长时间。它不是“断连后等多久重连”，而是“一次读操作卡住多久就判定失败”。设太大反而延迟感知故障，太小又容易误判闪断。
真实场景中，主从间RTT通常在1~10ms，但内核TCP重传、防火墙拦截、中间设备抖动会导致单次read阻塞达数秒。建议按网络质量分档：
- 局域网稳定环境：
slave_net_timeout = 60（默认值，够用） - 跨机房或云上VPC：
slave_net_timeout = 30，配合net_retry_count = 10（默认值，足够应对多数闪断） - 切忌设成
5或10：公网偶尔抖动就会频繁断连重试，加重主库连接压力
修改后需重启IO线程：STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，仅改变量不生效。
为什么SHOW SLAVE STATUS里Seconds_Behind_Master突然跳变归零又暴涨？
这不是数据追上了，而是IO线程重建连接后，从主库拉到了新的Exec_Master_Log_Pos，但SQL线程还没来得及执行，导致差值暂时为0；随后积压日志开始回放，延迟又快速上升。这是重连过程中的典型中间态，不代表同步正常。
真正要盯的是两个指标是否持续稳定：
-
Slave_IO_Running和Slave_SQL_Running必须同时为Yes -
Seconds_Behind_Master在无大事务前提下应缓慢收敛，而非反复归零/暴涨 - 如果
Last_IO_Error频繁出现 “connection lost” 类错误，说明底层网络或主库负载已不可靠，光调参数没用
主库高负载或慢查询拖垮从库重连？检查master_info_repository和relay_log_info_repository
当主从连接中断又恢复，从库需要重新定位同步位点。如果这两个元数据还存在文件中（FILE 模式），每次重连都要读写磁盘，遇到主库响应慢或从库I/O瓶颈，可能卡在初始化阶段，表现为IO线程状态长期为 Connecting。
- 务必设为
TABLE：SET GLOBAL master_info_repository = 'TABLE'; SET GLOBAL relay_log_info_repository = 'TABLE'; - 对应表
mysql.slave_master_info和mysql.slave_relay_log_info必须是InnoDB引擎（重启后自动创建，但旧实例可能仍是MyISAM） - 未切换前，
CHANGE MASTER TO会写文件；切完后，所有位点更新走事务，重连更快更可靠
网络闪断本身不可怕，可怕的是每次重连都触发一次磁盘寻道+锁表+解析日志。这一步漏掉，其他优化全打折扣。
