必须将wait_timeout和interactive_timeout设为相同值（如300或600秒），二者需在my.cnf的[mysqld]段配置并重启MySQL；连接池maxLifetime须比wait_timeout小至少30秒，且禁用autoReconnect=true。

因为不设或设得过大，MySQL 服务端不会主动回收空闲连接，而应用层又常复用已失效的连接——死连接就这么卡在中间，既占内存又锁资源。

wait_timeout 和 interactive_timeout 必须设为相同值

这两个参数不自动同步。只改 wait_timeout（影响 JDBC 等非交互式连接），而漏掉 interactive_timeout（影响 Navicat、mysql 命令行等），就会留下一批“长命”交互连接。攻击者或疏忽的 DBA 可以反复复用它们，绕过你对应用连接的限制。

• 生产环境建议统一设为 300（5 分钟）或 600（10 分钟），高并发短事务选前者
• 旧连接不会立即断开，需等自然超时或重启连接池才能清理干净
• 验证是否生效：执行 SHOW PROCESSLIST，找 State = 'Sleep' 且 Time > 600 的行；若仍有，说明配置未生效或连接正处在事务中

光靠 MySQL 断连接远远不够

MySQL 主动 kill 掉一个空闲连接后，应用层连接池如果没感知到，下次仍会把该连接借出去——结果就是报 MySQL server has gone away。这不是 MySQL 的问题，是连接池没对齐生命周期。

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• HikariCP 必须设 maxLifetime=270000（4.5 分钟），比 wait_timeout=300 少至少 30 秒
• Druid 对应参数是 maxEvictableIdleTimeMillis，同样要预留缓冲时间
• 禁用 autoReconnect=true：官方明确警告它会导致事务状态丢失、GTID 不一致

connect_timeout 是防“半开连接”的第一道防线

它管的是 TCP 握手 + 认证阶段，不是空闲时间。默认 10 秒够用，但别盲目调大——恶意扫描或 DNS 卡顿会让线程槽位被长期占用。

• 设为 10 是安全起点；网络差或用了 LDAP 认证时可临时调到 15
• 绝不能超过 30，否则一个坏 IP 就能拖住数分钟
• 它无法用 SET GLOBAL 动态修改，必须写进 my.cnf 并重启 MySQL
• 务必配合 max_connect_errors = 3 和 skip-name-resolve，否则封禁机制可能失效

最容易被忽略的是“隐式长事务”：事务已开始但没提交，连接就永远不算空闲，wait_timeout 完全不触发。这类连接在 SHOW PROCESSLIST 中显示为 Query 或 Updating，Time 持续增长——它们才是真正锁表、拖垮系统的元凶。