mysql服务端仅通过wait_timeout清理空闲非交互式连接，interactive_timeout仅影响命令行交互连接；需查实际值、配一致参数并重启生效，连接池须配合探活机制。
MySQL 服务端不会“自动断开用户连接”——它只对空闲的连接主动清理，且仅限非交互式连接；真正起作用的是 wait_timeout，不是用户登录态或账号权限控制。
查当前生效的 wait_timeout 和 interactive_timeout
别信文档默认值，不同 MySQL 版本、云厂商（如阿里云 RDS、AWS RDS）、甚至 JDBC 驱动是否带 CLIENT_INTERACTIVE 标志，都会影响实际走哪个参数。连上库后直接执行：
SELECT @@wait_timeout, @@interactive_timeout;
返回单位是秒。常见现象：
- 本地 MySQL 默认常为
28800（8 小时） - 阿里云 RDS 可能默认设成
300（5 分钟） - AWS RDS 强制最小值为
60，且不支持SET GLOBAL
注意：wait_timeout 控制 JDBC、PyMySQL、mysqlclient 等应用连接；interactive_timeout 只影响 mysql -u root -p 这类命令行交互连接。但部分连接池（如旧版 Druid）会显式声明交互模式，所以两个都得查、都得调。
永久修改 wait_timeout 必须改配置文件并重启
SET GLOBAL wait_timeout = 600 是临时的，MySQL 重启就回滚；生产环境必须写进配置文件。操作步骤：
- 编辑
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf（Linux），Windows 下是my.ini - 在
[mysqld]段落下添加两行（建议值一致，避免行为割裂）：wait_timeout = 600<br>interactive_timeout = 600
- 保存后执行
sudo systemctl restart mysql（不是reload）
⚠️ 不要往 [client] 段落里加——那只会改客户端行为，不影响服务端断连逻辑。
HikariCP / Druid 连接池必须配合验证机制，否则改了也白改
光调低 wait_timeout 不解决根本问题：连接池里存着一个已被 MySQL 断掉的连接，下次取出就报 MySQL server has gone away 或 Communications link failure。必须让连接池主动探活：
- HikariCP 推荐配：
connection-test-query=SELECT 1<br>validation-timeout=3000<br>idle-timeout=300000<br>max-lifetime=1800000
其中idle-timeout应比wait_timeout小至少 30 秒，留出网络延迟余量 - Druid 配：
testWhileIdle=true<br>timeBetweenEvictionRunsMillis=60000<br>minEvictableIdleTimeMillis=300000
- 绝对不要用
autoReconnect=true：MySQL 5.5+ 已废弃，它不重连，只抛异常，还可能破坏事务一致性
为什么设太小反而更容易出错
wait_timeout = 60 看似激进，但风险很高：
- 如果连接池没开验证，一次查询间隙超 60 秒，下一条语句必炸
- 长事务或慢查询不受影响——
wait_timeout只管“完全没发请求”的空闲期，不杀正在跑的 SQL - 云数据库（如腾讯云 CDB）可能限制最小值，设低于允许下限会被静默覆盖
- 某些监控脚本或定时任务连接 MySQL 后长期 hold 住连接，设太小会导致它们频繁重连失败
真正稳的做法是：让连接池的 max-lifetime 和 idle-timeout 略小于 wait_timeout，再配上可靠验证语句（如 SELECT 1），而不是单方面压低服务端阈值。
