MySQL wait_timeout设置未按预期生效及连接池适配问题咨询

一、GLOBAL wait_timeout设置后超时时间不符 #

• 会话级参数优先级：GLOBAL wait_timeout只对新建连接生效，已存在的连接沿用创建时的SESSION wait_timeout值。测试前要确认用的是设置后新建的连接，可执行SELECT @@SESSION.wait_timeout查看当前会话的超时值，或用SHOW PROCESSLIST核对连接创建时间。
• 别混淆interactive_timeout：如果使用交互式客户端（比如mysql命令行），超时由interactive_timeout控制，而非wait_timeout。需同时设置GLOBAL interactive_timeout=600，再新建连接测试。
• 排查系统/网络超时：服务器的TCP keepalive配置、防火墙或负载均衡的空闲连接超时规则，都可能覆盖MySQL的设置，导致实际超时更长。检查这些环节的超时时间是否大于600秒。

二、连接池启用后wait_timeout完全失效 #

• 连接复用导致会话参数不更新：连接池里的长连接，会话级wait_timeout是创建时的全局值，后续修改GLOBAL参数不会自动更新已有连接。必须在连接池的初始化逻辑里，强制给每个新连接执行SET SESSION wait_timeout=600，确保会话参数生效。
• 连接池空闲超时冲突：多数连接池自带空闲连接回收机制（比如HikariCP的idleTimeout、Druid的keepAlive），如果连接池的空闲超时设得比MySQL的wait_timeout大，连接池会在MySQL回收连接前复用它，看起来像wait_timeout没起作用。把连接池的空闲超时设为小于600秒（比如550秒），让连接池先回收空闲连接。
• 参数未持久化：仅用SET GLOBAL wait_timeout=600是临时设置，MySQL重启后会恢复到配置文件默认值。在my.cnf（Windows为my.ini）中添加以下配置，再重启服务：

  wait_timeout = 600
  interactive_timeout = 600
  

• 连接池配置未加载：检查连接池的配置是否正确生效，有没有配置项禁用了会话参数自定义，或覆盖了你设置的超时值。比如部分连接池默认会忽略会话级设置，需开启允许自定义的选项。

验证建议 #

• 修改参数后，新建连接执行SELECT @@GLOBAL.wait_timeout, @@SESSION.wait_timeout，确认全局和会话参数都正确。
• 测试超时用非交互式客户端（比如应用程序连接），避免interactive_timeout干扰。
• 临时关闭连接池，用普通连接测试wait_timeout是否生效，先排除连接池的问题。

内容的提问来源于stack exchange，提问作者M.Abdullah Iqbal