MySQL连接超时：一个需要数据库与应用层协同解决的经典问题
处理MySQL连接超时，从来不是单方面调整某个参数就能一劳永逸的。它更像是一场需要数据库端和应用端精密配合的“双人舞”。数据库侧需要统一设置wait_timeout和interactive_timeout并确保持久化到my.cnf；而应用侧则必须配置好连接池的maxLifetime、连接验证以及JDBC超时参数。任何一方的缺席，都会让整个优化方案失效。
这里有一个核心概念必须厘清：wait_timeout和interactive_timeout控制的仅仅是“空闲断连”。它们与连接建立失败或查询卡死的超时完全是两码事——这两个参数只在连接已经建立、却长时间没有收到任何新语句时才会生效。
为什么明明改了wait_timeout，还是遇到“MySQL server has gone away”？
因为这个错误提示往往不是空闲超时直接触发的，而是连接已经被服务端关闭后，应用层还在试图复用这个“僵尸连接”。背后常见的原因有几个：
wait_timeout已经生效，但应用连接池（比如HikariCP）没有设置maxLifetime，导致连接在服务端被回收后，依然被连接池分配出去使用。- 客户端发起了一个大型查询，处理时间超过了
net_read_timeout的限制，服务端主动中断了读取操作，但应用层没有妥善捕获这个异常。 - 网络链路中的中间件（例如ProxySQL、LVS）拥有自己独立的空闲超时设置，其断连时机可能早于MySQL本身。
如何验证是否是wait_timeout导致的？一个直接的方法是执行SHOW PROCESSLIST;命令，观察那些状态为Sleep的连接，看看它们的持续时间是否已经接近你设定的超时值。
wait_timeout和interactive_timeout必须设成一样吗？
严格来说，不一定。但生产环境强烈建议将它们设置为相同的数值。这二者的区别在于：
wait_timeout作用于非交互式连接，这涵盖了绝大多数应用连接、后台脚本以及连接池获取的连接。interactive_timeout仅影响带有CLIENT_INTERACTIVE标志的连接（例如使用--interactive参数启动的mysql命令行客户端，或在JDBC URL中显式设置了interactiveClient=true的情况）。
问题的复杂性在于：许多JDBC驱动默认并不会设置这个标志，但某些ORM框架（如旧版本的Hibernate）或像Python的PyMySQL这样的库，在特定条件下可能会误设此标志。这就导致同一个应用里，部分连接遵循interactive_timeout，另一部分则遵循wait_timeout，造成超时行为的不一致。因此，统一设置为相同值是最稳妥的策略。
怎么修改才能真正生效？重启并非唯一途径
动态修改参数是可行的，但需要注意权限和作用范围：
- 需要拥有
SUPER权限才能执行SET GLOBAL wait_timeout = 600;这类命令。 - 动态修改只对新建立的连接立即生效，已经存在的连接仍然保持原有的超时设置。
- 一旦MySQL服务重启，所有动态设置的值都会丢失，必须写入配置文件才能持久化。
配置文件通常位于：/etc/my.cnf、/etc/mysql/my.cnf或/usr/etc/my.cnf；Windows系统下则是my.ini。修改时，请在[mysqld]配置段下添加：
[mysqld] wait_timeout = 600 interactive_timeout = 600
修改完成后，务必进行确认：执行SHOW VARIABLES LIKE 'wait_timeout';，查看输出值是否与你设定的新值一致。如果显示的仍然是默认的28800，那通常意味着配置文件没有加载成功（可能是路径错误、配置段名错误或语法问题），或者设置被其他后续加载的配置覆盖了。
应用层不配合，数据库端调得再精细也是徒劳
数据库的职责是定义“我等你多久”，它并不关心“你到底用不用”。真正防止超时错误的关键，其实在应用侧。以下几个配置缺一不可：
- 连接池必须启用连接验证：例如在HikariCP中配置
connection-test-query=SELECT 1或设置validation-timeout=3000。 - 合理设置maxLifetime：连接池中连接的最大生命周期应比
wait_timeout至少短60秒。例如，若wait_timeout=600（秒），则maxLifetime应设为540000（毫秒）。 - 完善JDBC超时参数：在JDBC连接URL中，建议加上
socketTimeout=30000&connectTimeout=5000，分别控制网络读写超时和建立连接的超时（单位均为毫秒）。
这里有一个极易被忽略的陷阱：当wait_timeout被调小后，如果应用端没有配置连接有效性检查，那么很可能在凌晨业务低峰期出现批量报错。原因在于，大量空闲连接被MySQL服务端关闭，而连接池对此一无所知，次日业务高峰来临时，这些失效的连接被直接分配给业务代码使用，执行查询瞬间就会抛出“Lost connection to MySQL server during query”错误。
