数据库连接池心跳保活核心是应用层主动探测连接可用性，需Druid配置testWhileIdle=true、timeBetweenEvictionRunsMillis=30000、validationQuery=SELECT 1，并匹配MySQL的wait_timeout=180等参数，避开驱动兼容、防火墙丢包等陷阱。
数据库连接池的心跳自动保活，核心是让应用层主动探测连接是否真实可用，而不是被动等待 TCP 断连或数据库超时。它不是靠“等死”，而是定期“敲门确认”。实现效果取决于三方面配合：连接池自身的保活逻辑、数据库服务端的超时策略、以及网络中间设备（如防火墙、NAT）的行为。
Druid 连接池启用保活的关键配置
Druid 是最常用也最典型的例子。它不依赖操作系统 TCP Keepalive（默认 2 小时才触发），而是在应用层启动守护线程，周期性对空闲连接发起轻量级验证。
-
开启保活开关：设置
testWhileIdle=true，表示允许在连接空闲时做有效性检查 -
设定检查间隔：
timeBetweenEvictionRunsMillis=30000（推荐 30 秒），这是守护线程扫描连接池的周期 -
指定验证 SQL：
validationQuery=SELECT 1（MySQL）或SELECT 1 FROM DUAL（Oracle），必须是极快返回的语句 -
控制空闲阈值：
minEvictableIdleTimeMillis=60000（如设为 60 秒），表示空闲超 60 秒才纳入保活检查范围；避免刚创建就查
与数据库服务端参数对齐
光客户端保活还不够——如果数据库自己先把连接关了，而连接池还不知道，就会出现“查到一半报错：The last packet successfully received from the server was X milliseconds ago”。所以必须匹配两端超时。
- 查 MySQL 当前设置：
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';，默认是 28800 秒（8 小时），太长 - 建议生产环境设为
wait_timeout = 180（3 分钟），再配合 Druid 的 30 秒保活，留出安全余量 - 确保
interactive_timeout也同步调整，否则某些客户端行为可能走另一套逻辑 - 容器部署时，务必写进
my.cnf，用SET GLOBAL临时改会在重启后丢失
避开常见陷阱
很多故障不是没配，而是配得“看起来对、实际错”。
-
验证 SQL 不生效：有些数据库驱动（如旧版 MySQL Connector/J）会忽略
validationQuery，需确认驱动版本支持，并开启useServerPrepStmts=false避免预编译干扰 -
防火墙静默丢包：即使 TCP 层没断，中间设备可能在 5–10 分钟后直接丢弃空闲连接。这时仅靠数据库
wait_timeout不够，必须靠 Druid 主动发SELECT 1才能暴露问题 -
连接池大小与保活冲突：若
maxActive设得过大（比如 200），但业务实际并发只有 20，大量连接长期空闲，又没及时驱逐，反而增加保活负担和失败概率。建议结合监控动态调优 -
日志没开，等于没配：加上
logAbandonedOnBorrow=true和removeAbandonedOnBorrow=true，能快速定位被异常占用或失效的连接
验证是否真正生效
配完不能只看启动日志，要实测。
- 停掉数据库服务，观察应用日志是否在 30 秒内报出连接校验失败，而非等到首次 SQL 执行才崩
- 用
netstat -an | grep :3306 | grep ESTABLISHED | wc -l查看真实活跃连接数，对比 Druid 监控指标（如ActiveCount、PoolingCount）是否一致 - 在 Druid 内置监控页（
/druid/index.html）中查看 “LastValidConnectionCheckTime” 是否持续更新
