只改wait_timeout无效，因其会话值初始化时继承全局interactive_timeout；非交互式连接（如java应用）虽受wait_timeout控制，但新连接仍按interactive_timeout值初始化，故须同时设置二者且写入配置文件并重启。
为什么只改 wait_timeout 没用？
因为 MySQL 会根据客户端类型（交互式 or 非交互式）分别应用 wait_timeout 或 interactive_timeout。Java 应用、Python mysql-connector、Go database/sql 等绝大多数驱动默认建立的是「非交互式连接」，走 wait_timeout；但某些 CLI 工具、MySQL Workbench、或显式传了 CLIENT_INTERACTIVE 标志的连接，则走 interactive_timeout。更关键的是：会话级 wait_timeout 初始化值，直接继承自全局 interactive_timeout —— 这意味着，即使你只改了 wait_timeout 的全局值，新连接仍可能按旧的 interactive_timeout 值初始化，导致修改看似“失效”。
必须同时设置 wait_timeout 和 interactive_timeout
二者必须设为相同值，且需在配置文件的 [mysqld] 段中显式声明，不能只靠运行时 SET GLOBAL。原因如下：
-
SET GLOBAL wait_timeout = 300只影响后续新建连接的初始值，但不改变已存在连接的会话变量，也不影响interactive_timeout的取值逻辑 - 若配置文件里只写了
wait_timeout = 300，而interactive_timeout未定义，MySQL 就会回退到编译默认值（8.0 是 28800），新连接仍按 28800 初始化wait_timeout - Docker 容器或云 RDS 中，配置可能被多层覆盖（如
/etc/mysql/mysql.conf.d/docker.cnf优先于/etc/my.cnf），必须确认最终生效的文件
正确写法（放入 /etc/mysql/mysql.conf.d/mysqld.cnf 或对应主配置文件）：
[mysqld] wait_timeout = 300 interactive_timeout = 300
改完配置不生效？检查这三处
别只信配置文件，运行时值和加载路径才是真相：
- 执行
SHOW VARIABLES LIKE 'wait_timeout';和SHOW VARIABLES LIKE 'interactive_timeout';，确认两个值一致且为你设的数值 - 运行
mysqld --help --verbose | grep "Default options"，看它实际加载了哪些路径，逐个打开搜索wait_timeout，注意!includedir下文件的字母序覆盖规则（z-custom.cnf会盖过a-base.cnf） - 检查是否有多个
[mysqld]段——只有最后一个段里的同名参数生效；若某段末尾有!include，它引入的文件也参与覆盖
应用层不配合，数据库调再小也没用
把 wait_timeout 改成 300 秒（5 分钟）只是起点，不是终点。真正容易被忽略的是连接池行为：
- HikariCP 必须设
maxLifetime（建议设为 250000，即比 300 秒小 50 秒），否则连接池会复用一个已被 MySQL 关闭的连接 - Druid 要开
testWhileIdle = true+timeBetweenEvictionRunsMillis = 60000，否则空闲连接不会被主动探测和剔除 - Spring Boot 2.3+ 默认禁用
auto-commit与连接有效性检测，需显式配spring.datasource.hikari.connection-test-query=SELECT 1或启用validation-timeout
最隐蔽的坑：升级 MySQL 后，mysql_upgrade 可能清空了运行时变量，但没写回配置文件——你看到的 SHOW VARIABLES 值是临时的，重启就丢。务必确认修改已落盘并重启 mysqld 进程，而非客户端或应用服务。
