MySQL连接器是如何管理空闲连接并防止自动断开的？-mysql教程-PHP中文网

直接执行select @@wait_timeout, @@interactive_timeout;或show variables like 'wait\_timeout'等语句查询最准确，且两值必须一致；连接池需设maxlifetime/maxevictableidletimemillis比wait_timeout小30–60秒，并启用连接验证与心跳，禁用autoreconnect=true，代码中须用try-with-resources或finally显式关闭资源。

mysql连接器是如何管理空闲连接并防止自动断开的？

MySQL服务端的wait_timeout和interactive_timeout怎么查？

别信文档写的28800秒，默认值在不同环境里经常被覆盖：云数据库可能设成300秒，Docker镜像可能继承了基础镜像配置，JDBC驱动加了CLIENT_INTERACTIVE标志还会让连接走interactive_timeout路径。直接连上去查最准：

SELECT @@wait_timeout, @@interactive_timeout;
SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';

注意两个值必须一致——如果差很多，说明服务端行为已经分裂，后续排查会绕弯子。

HikariCP或Druid连接池怎么配才能不被MySQL踢掉？

连接池不是“等MySQL断它”，而是主动在MySQL断之前清理掉空闲连接。关键不是拉长wait_timeout，而是让池子的生命周期参数严格小于它：

maxLifetime（HikariCP）或maxEvictableIdleTimeMillis（Druid）必须比wait_timeout小至少30–60秒，比如MySQL设为3600秒（1小时），池子就设3500000毫秒
必须开启连接验证：connection-test-query=SELECT 1（MySQL 8.0+可用isValid()代替），配合validation-timeout=3000
避免test-on-borrow=true这种每次取连接都查一次的重操作；更轻量的是开keepalive-time=30000（每30秒发一次心跳）

如果maxLifetime ≥ wait_timeout，连接池会把一个MySQL早已关闭的连接再分配出去，下一次使用直接抛Communications link failure。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

为什么autoReconnect=true不能用？

MySQL Connector/J 5.5+已废弃该参数，它根本不会自动重连，只会在报错后抛异常，且掩盖真实问题：

事务状态丢失：前一条语句已提交，重连后下一条在新会话执行，造成逻辑断裂
会话变量、预编译SQL、用户变量全部清空
锁被释放，可能导致并发数据不一致
错误日志里还是会出现CommunicationsException，但你误以为“重连成功”而忽略连接池配置

官方文档明确标注废弃，生产环境禁止配置autoReconnect=true。

应用代码里哪些地方容易漏掉连接释放？

连接池管的是“归还”，不是“销毁”；归还的前提是代码里显式释放资源：

没用try-with-resources，或finally块里漏写connection.close()、statement.close()、resultSet.close()
Spring Boot + MyBatis场景下，@Transactional方法提前return，事务没结束，SqlSession绑定的连接卡在线程上不归还
流式查询（如Stream<entity></entity>）没及时消费完，连接一直被占用

哪怕连接池配置再合理，只要有一处close()没调，就会积压Sleep连接，最终触发MySQL server has gone away。