问题场景

应用程序使用MySQL的user lock，在MySQL客户端与MySQL服务端连接建立后，接着通过网络工具模拟drop数据丢包，此时再尝试拿锁，一直提示锁存在，约2小时后才可以加锁成功。

核心结论

如果连接是在数据传输中被 DROP，会触发 net_read_timeout / net_write_timeout （默认几十秒），不会等 2 小时；2 小时释放基本可以判定是空闲连接场景下的超时释放。

连接约 2 小时才释放，最常见的原因是 Linux 操作系统默认的 TCP Keepalive 保活探测机制触发，其次是 MySQL 空闲超时参数被主动配置为 2 小时，也可能由中间网络设备的会话超时导致。以下是分层分析：

一、最可能原因：操作系统 TCP Keepalive 机制（默认 2 小时触发）

这是默认配置下最符合“约 2 小时释放”现象的原因。

机制原理

1. MySQL 侧的 tcp_keepalive_time 参数默认值为 0，表示直接复用操作系统内核的 TCP 保活配置，不单独设置。
2. Linux 系统内核默认参数：

• net.ipv4.tcp_keepalive_time = 7200 ：TCP 连接空闲 2 小时后，内核开始向对端发送保活探测包。
• net.ipv4.tcp_keepalive_probes = 9 ：连续发送 9 次探测包，无响应则判定连接失效。
• net.ipv4.tcp_keepalive_intvl = 75 ：每次探测间隔 75 秒。

3. 网络 DROP 场景下，客户端无法响应探测包，内核走完完整探测流程后，会标记 TCP 连接为失效，并通知 MySQL 进程关闭连接、释放线程和内存资源。

• 总耗时 ≈ 7200 + 9×75 = 7875 秒 ≈ 2 小时 11 分钟，与“约 2 小时”的观察高度吻合。

为什么不是 MySQL 默认的 8 小时超时？

MySQL 应用层的 wait_timeout 默认是 8 小时，但内核层面的 TCP 保活检测触发更早。在僵死空闲连接场景下，内核会先于 MySQL 应用层判定连接死亡并回收，MySQL 会跟随内核状态释放连接，因此表现为 2 小时左右释放。

二、次可能原因：MySQL 空闲超时参数被配置为 2 小时

很多生产环境会主动调小空闲超时，避免大量僵死连接长期占用资源，这也是常见原因。

1. 参数说明

• wait_timeout ：控制非交互式连接（应用程序、连接池）的空闲超时，默认 28800 秒（8 小时）。
• interactive_timeout ：控制交互式连接（mysql 命令行客户端）的空闲超时，默认 28800 秒（8 小时）。

2. 两种修改场景

• 全局配置： my.cnf 配置文件中手动设置了 wait_timeout=7200 （2 小时），MySQL 启动后全局生效。
• 会话级修改：应用程序/连接池在建立连接后，执行 SET SESSION wait_timeout=7200; ，仅对当前连接生效，不影响全局配置。

三、其他可能原因：中间链路的会话超时

如果 MySQL 与客户端之间存在中间网络设备，连接释放时间可能由中间设备决定：

1. 防火墙 / 安全组：网络防火墙、云安全组的 TCP 会话超时通常配置为 1~2 小时，超时后会主动清理会话表，两端感知后释放连接。
2. 数据库代理：如 HAProxy、ProxySQL、MaxScale 等中间件，自身配置了连接空闲超时（常见 2 小时），由代理端主动断开与 MySQL 服务端的连接。
3. 负载均衡器：LVS、Nginx 等四层/七层负载均衡的 TCP 会话超时，也可能成为最早触发断连的阈值。

四、快速验证方法

按优先级依次排查：

1. 确认 MySQL 超时参数

  
-- 检查全局和会话级空闲超时
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW SESSION VARIABLES LIKE 'wait_timeout';
-- 检查 MySQL 自身的 TCP 保活配置
SHOW VARIABLES LIKE 'tcp_keepalive%';

2. 确认操作系统 TCP 保活参数

  
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_intvl

3. 排查中间链路
   确认客户端与 MySQL 之间是否有代理、防火墙、负载均衡，并核对其 TCP 会话/空闲超时配置。