远程MySQL拔除网线断连后查询等待1分钟才感知离线的原因排查

首先明确两类断连场景的本质差异：

• 通过服务控制面板停止MySQL服务时，服务进程会主动关闭所有持有的TCP连接，操作系统会立刻向客户端发送FIN/RST控制报文，客户端收到报文后会马上标记连接失效，因此可以快速识别离线状态
• 直接拔除网线的物理断网场景下，TCP链路没有任何主动通知信令，客户端只能依靠各类超时机制判断连接有效性，感知中断的等待时长本质是多层超时阈值的累计值，具体诱因包含以下几类：
• 操作系统层面的TCP重传超时默认配置：主流Windows、Linux操作系统的TCP协议栈，默认在数据包未收到对端ACK确认时，会按照指数退避策略进行5-6次重传，累计等待时长刚好在60秒上下的区间，这也是你观察到刚好等1分钟的核心来源。物理断网时，应用发送的数据库请求会先写入操作系统的发送缓冲区，由于收不到远端的ACK响应，系统会逐次重传直到达到最大重传次数，才会向上层应用抛出连接超时错误。
• JDBC驱动的应用层超时配置缺失：MySQL官方JDBC驱动的socketTimeout参数默认值为0，代表应用层不设置任何读取超时逻辑，完全将超时判断交给操作系统TCP栈处理。这种配置下，驱动发送完SQL请求后不会主动校验链路连通性，只会在读取响应时阻塞等待，最终撞上操作系统层面的默认超时阈值。
• 连接复用流程的有效性检测缺位：哪怕是基于DriverManager手动实现的连接管理逻辑（或轻量封装的连接池），如果没有在借出连接前配置带超时的有效性校验，就会把已经因物理断网失效的连接直接传递给业务查询流程，让查询逻辑直接触发全链路的超时等待，而不是在获取连接阶段就快速捕获异常。
• 管理类查询的交互特性放大等待感知：你观察到执行show slave status时等待现象更显著的现象，和这类查询的自身逻辑直接相关。普通业务查询的响应链路通常较短，而show slave status需要采集复制线程状态、中继日志位置、延迟值等多模块运行数据才会返回结果，客户端发送请求后会进入无主动心跳校验的长阻塞读取状态，一旦链路失效，没有任何应用层的中断触发机制，等待时间会被更完整地暴露出来。

内容的提问来源于stack exchange，提问作者Elif Şahin