mysql升级后wait_timeout相关超时，主因是配置重载导致timeout回退默认值28800秒，而应用连接池未适配回收策略，造成sleep连接堆积；需优先检查并同步调整连接池maxlifetime与数据库wait_timeout，再修改配置文件中[mysqld]段的wait_timeout和interactive_timeout值并重启服务。
MySQL 升级后连接超时，大概率是 wait_timeout 或 interactive_timeout 被重置为默认值（28800 秒），但应用层连接池没及时回收或心跳机制失效，导致大量 Sleep 连接堆积，最终触发连接数打满或连接被服务端单方面断开。
为什么升级后突然出现 wait_timeout 相关超时？
MySQL 升级过程会重载配置文件，而很多发行版（如 Ubuntu 22.04+）在升级后会把原 /etc/my.cnf 拆成多文件加载，比如 /etc/mysql/conf.d/mysql.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf。如果这些新配置里没显式设置 wait_timeout，就会回退到编译默认值——8.0 是 28800 秒，但某些容器镜像或打包版本可能设得更短（甚至 60 秒）。
更隐蔽的是：升级后 mysql_upgrade 可能清空了运行时变量，但没同步写入配置文件，导致你查 SHOW VARIABLES LIKE 'wait_timeout'; 看到的值是临时生效的，重启就丢。
怎么确认当前生效的 timeout 值和来源？
别只信配置文件，先看实际运行值：
- 连上 MySQL 后执行：
SHOW VARIABLES LIKE 'wait_timeout';和SHOW VARIABLES LIKE 'interactive_timeout'; - 再查配置加载路径：
mysqld --help --verbose | grep "Default options"，然后逐个打开列出的文件（如/etc/my.cnf、/etc/mysql/conf.d/下所有.cnf），搜索wait_timeout出现的位置 - 注意：多个
[mysqld]段落时，只有最后一个段落里的同名参数生效；若某文件末尾有!includedir /etc/mysql/conf.d/，那目录下按字母序加载，z-mysql.cnf会覆盖a-base.cnf
改配置还是改应用？优先级怎么排？
单纯调大 wait_timeout 是饮鸩止渴——它只是让 Sleep 连接活得更久，不解决连接泄漏。正确顺序是：
- ✅ 先检查应用是否用了连接池（如 HikariCP、Druid）；没用的话，必须加，不能直连
- ✅ 连接池要设
maxLifetime（建议比wait_timeout小 30–60 秒）和idleTimeout（建议 300–1800 秒） - ✅ 再调整 MySQL 端：
wait_timeout = 300（5 分钟）、interactive_timeout = 300，写进[mysqld]段并重启mysqld（不是mysql客户端） - ⚠️ 别只改
my.cnf就以为完事——Docker 镜像里可能挂载了宿主机配置，但容器内实际读的是镜像自带的/etc/mysql/mysql.conf.d/docker.cnf
连接已超时断开，怎么快速验证是不是 timeout 导致？
直接看连接状态和时间戳：
- 执行：
SHOW PROCESSLIST; - 重点过滤：
Command = 'Sleep'且Time > 300的行（说明空闲超 5 分钟） - 如果这类连接占总数 70% 以上，且应用日志里反复出现
Connection reset或Communications link failure，基本锁定是 timeout + 连接池未回收 - 临时验证：在会话里执行
SET SESSION wait_timeout = 60;，再等 60 秒，看连接是否自动断开（可配合mysql -e "SELECT 1;"循环测试）
真正麻烦的不是改哪个数字，而是升级后没人去核对连接池的 maxLifetime 是否还匹配数据库的 wait_timeout——这两个值一旦错位，Sleep 连接就会像雪球一样越滚越大，直到某天凌晨三点爆满。
