wait_timeout只清理sleep状态的空闲连接，对updating/locked等活跃状态的僵尸事务无效；需配合客户端连接池配置及主动kill干预长事务。
wait_timeout 能清理哪些连接？只杀 Sleep，不碰 Updating/Locked
wait_timeout 的作用非常明确：它只对状态为 Sleep 且**完全空闲**（无任何未完成语句、未持锁、未等待网络响应）的非交互式连接生效。网络抖动后卡在 Updating、Locked 或 Writing to net 的僵尸事务，wait_timeout 完全无视——因为 MySQL 认为“它还在干活”。你查 SHOW PROCESSLIST 会看到 Time 字段可能只有几秒，但 trx_started 已经是十分钟前，这种连接不会被自动断开。
怎么设值才真正起效？必须和服务端+客户端配置对齐
设成 300（5 分钟）或 900（15 分钟）是常见安全值，但光改服务端没用：
- 修改必须写入
/etc/my.cnf的[mysqld]段，并重启 MySQL 或用SET GLOBAL wait_timeout = 300（需 SUPER 权限），之后新建连接才生效 - 已有连接沿用旧值，得手动
KILL或等自然断开 - 应用连接池（如 HikariCP）的
idle-timeout必须比wait_timeout小至少 60 秒，否则池子会提前驱逐健康连接，引发重连风暴 - 务必同步配
connection-test-query=SELECT 1和validation-timeout=3000，否则池子里的“假活”连接取出即报MySQL server has gone away
为什么 SHOW VARIABLES 看不到刚 SET 的值？默认查的是会话变量
执行 SET GLOBAL wait_timeout = 300 后，如果直接 SHOW VARIABLES LIKE 'wait_timeout'，返回的仍是旧值——因为它查的是当前会话的变量副本。要确认全局是否生效，必须用：
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
同样，interactive_timeout 也得一起设，且建议与 wait_timeout 值一致，避免交互式工具（如 Navicat）行为不一致。两者都只影响新连接，老连接不会热更新。
现有大量 Sleep 连接怎么快速清掉？别等超时，主动 KILL 更可靠
当 SHOW PROCESSLIST 里出现上百个 Sleep 连接，且 Time 超过 300 秒时，靠 wait_timeout 等它自己死太慢。安全清理步骤是：
- 先排除后台线程：
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ? AND THREAD_TYPE != 'FOREGROUND' - 再确认不是备份或 DDL：
SELECT INFO FROM information_schema.PROCESSLIST WHERE ID = ?，避开ALTER TABLE、mysqldump类操作 - 最后执行
KILL CONNECTION [id]（不是KILL QUERY，后者对Sleep无效） - 批量清理时分批进行，每次不超过 20 个，避免瞬时回滚压力拖慢实例
真正难处理的从来不是 Sleep 连接，而是那些 INFO IS NULL + STATE = 'Locked' + trx_started 很老的事务——它们根本不在 wait_timeout 的管辖范围，必须靠 INNODB_TRX 主动识别和人工干预。
