“waiting for master to send event”是从库i/o线程正常空闲等待主库推送binlog事件的状态，表明复制连接正常、未中断，仅主库暂无新事务写入。
这是从库 I/O 线程的正常等待状态，不是故障，也不代表连接泄漏或复制卡住。
Waiting for master to send event 是什么状态
它是 SHOW PROCESSLIST 中 system user 所属的 I/O 线程显示的状态，表示：从库已成功连接主库，当前正空闲等待主库推送新的 binlog 事件。主库没写入、没提交事务时，这个状态就会持续存在——就像快递员在小区门口等你下单，没单子就站着不动。
常见误判点：
- 把该状态和应用层的
Sleep连接混为一谈（后者是客户端连接池未释放，Host列显示的是应用 IP） - 看到
Time值高达几万秒就认为“连接挂了”，其实对 I/O 线程而言，Time是它持续等待的秒数，只要Seconds_Behind_Master不涨，就是健康的 - 在主库低流量期看到这个状态，误以为复制中断，实际只是“等活干”
什么时候需要真正关注这个状态
仅当它伴随以下现象出现时才需排查：
-
Slave_IO_Running: No（I/O 线程已停止），此时状态会消失，Slave_IO_State变为空或Connecting to master -
Seconds_Behind_Master持续增长，且Read_Master_Log_Pos长时间不更新（说明 I/O 线程没拉到新日志） - 同时出现
Last_IO_Error非空，比如error connecting to master或超时类报错 - 主库
show master status的Position在推进，但从库Read_Master_Log_Pos卡死不动
这时要查网络连通性、主库 binlog 是否被 purge、slave_net_timeout 设置是否过小（默认 60 秒，太小会导致频繁重连）。
为什么改了 connect_timeout 还是反复重连
很多人调大 connect_timeout，但无效——因为 I/O 线程的重连行为主要受两个参数控制：
-
slave_net_timeout：I/O 线程等待主库发事件的超时阈值。超时后主动断开并重连，**不是连接建立阶段的 timeout** -
master_connect_retry：重连失败后的休眠间隔（单位秒），默认 60，可设为 10–30 加快恢复
执行以下命令确认当前值：
SELECT @@slave_net_timeout, @@master_connect_retry;
修改需在从库执行：
SET GLOBAL slave_net_timeout = 300;<br>CHANGE MASTER TO MASTER_CONNECT_RETRY = 30;
注意：slave_net_timeout 必须大于主库 net_write_timeout，否则可能被主库主动 kill。
容易被忽略的底层依赖
这个状态看似简单，实则隐含三个关键依赖未被显式暴露：
- 主库必须开启
binlog_format = ROW或MIXED（STATEMENT在某些函数下不可靠，易导致 I/O 线程异常退出） - 主库账号需有
REPLICATION SLAVE权限，且不能被sql_log_bin=0会话绕过（否则从库收不到事件） - 从库磁盘空间不足时，I/O 线程写 relay log 失败，状态可能卡在
Queueing master event to the relay log，而非此状态——但现象类似，需查Relay_Log_Space和错误日志
真正危险的从来不是 “Waiting for master to send event”，而是你盯着它看太久，却漏掉了 Relay_Log_Space 已达 98% 或 SQL_Delay 被意外开启这类静默问题。
