生产环境中将wait_timeout和interactive_timeout设为300秒最有效，因默认28800秒易导致事务锁残留、连接泄漏及资源耗尽，需同步配置应用层连接池maxlifetime、validationquery等参数才能真正规避风险。
wait_timeout 和 interactive_timeout 设为 300 秒（5 分钟）是生产环境中预防连接堆积与锁残留最有效的起点；单纯调高超时值反而会放大死锁影响、掩盖应用层事务控制缺陷。
为什么默认 28800 秒（8 小时）在生产中不安全
MySQL 默认的 wait_timeout 和 interactive_timeout 均为 28800 秒，但这个值面向的是本地调试场景。真实业务里，一个“挂起”的连接可能意味着：
– 事务已开始但未提交，持续持有行锁或间隙锁
– 应用端因异常未关闭连接，连接池误复用该连接导致后续查询报 MySQL server has gone away
– 攻击者利用长空闲连接耗尽 max_connections 资源，触发拒绝服务
这些都不是理论风险——SHOW PROCESSLIST 中大量 Sleep 状态且 Time > 300 的连接，基本可判定为隐患。
必须同步调整的四个关键 timeout 参数
只改服务端变量而不配应用层，等于只关一扇窗却开着整面墙：
-
wait_timeout：非交互式连接（如 Java JDBC）空闲超时，建议设为300；若用 HikariCP，需同步设maxLifetime=270000（4.5 分钟），确保连接在被 MySQL 主动断开前被池回收 -
interactive_timeout：仅影响mysql命令行等交互式登录，可设为600，避免 DBA 忘记退出时长期占连接 -
connect_timeout：TCP 握手+认证阶段超时，设为10即可；值过大（如 30）会让网络抖动时线程卡死更久 -
innodb_lock_wait_timeout：事务等锁放弃阈值，OLTP 场景推荐15；它不解决死锁，只控制“等多久就报错”，设太高会导致监控里Lock wait timeout exceeded日志延迟出现，掩盖真实锁争抢热点
应用层 JDBC 连接字符串里不能漏掉的两个 timeout
JDBC 驱动层超时和 MySQL 服务端超时是两套独立机制，缺一不可：
-
connectTimeout=5000：单位毫秒，控制建立 TCP 连接最大等待时间；跨云环境建议设到10000，但绝不应超过服务端connect_timeout（单位秒） -
socketTimeout=30000：单位毫秒，控制单次 SQL 执行读写阻塞上限；必须小于应用 HTTP 接口超时（如 Spring Boot 的server.tomcat.connection-timeout），否则会出现“数据库已断开但 HTTP 请求还在等”级联超时 - 禁用
autoReconnect=true：MySQL 官方文档明确警告其可能导致事务状态丢失、主从 GTID 不一致；连接有效性靠validationQuery=SELECT 1+testOnBorrow=true更可靠
最容易被忽略的“隐式长事务”陷阱
很多锁超时根本不是 timeout 设置问题，而是应用代码把事务边界撑得太宽：
- Spring
@Transactional方法里调用了外部 HTTP 接口，整个 HTTP 耗时都算进事务持锁时间 - 循环内执行 N 次
UPDATE，没批量改写，每次更新都触发一次锁获取+释放，放大竞争概率 - 事务中做了文件读写、加解密、复杂计算，MySQL 完全感知不到，但它持有的锁一秒都不松
- 解决方案不是调大
innodb_lock_wait_timeout，而是拆事务、加索引、用SELECT ... FOR UPDATE SKIP LOCKED规避排队
SHOW PROCESSLIST 里一眼识别出哪些 Sleep 连接是正常的、哪些是泄漏的；以及当 Lock wait timeout exceeded 出现时，第一反应是查慢日志里的 WHERE 条件有没有走索引，而不是立刻去调参数。
