连接池需预热、maxLifetime须小于数据库wait_timeout、borrowTimeout是排队超时而非SQL超时。预热确保minIdle连接可用；maxLifetime应设为wait_timeout的70%～90%；borrowTimeout需按P95耗时2～3倍设置，避免线程饥饿或误失败。
连接池初始化时必须预热空闲连接
很多应用启动后首次查询慢，本质是连接池没预热，第一个请求被迫创建物理连接。数据库连接建立涉及 TCP 握手、SSL 协商、认证、会话初始化，耗时远高于后续复用。
预热的关键不是“填满”连接池，而是确保至少有 minIdle 个已验证可用的空闲连接。例如 HikariCP 中设置 initializationFailTimeout=1（毫秒）并配合 connection-test-query=SELECT 1（MySQL）或 connection-test-query=SELECT 1 FROM DUAL（Oracle），可强制启动时校验并填充。
- 避免用
autoReconnect=true这类 JDBC 参数代替预热——它只在异常后重连，不解决冷启动延迟 - PostgreSQL 需用
connection-test-query=SELECT 1，不能依赖testOnBorrow（已废弃） - 预热失败应阻断启动，而非静默降级；否则线上可能持续使用未验证连接导致批量超时
maxLifetime 必须严格小于数据库的 wait_timeout
MySQL 默认 wait_timeout=28800（8 小时），但连接池若设 maxLifetime=30000000（约 8.3 小时），连接会在数据库侧被服务端主动断开，而池中仍认为有效，下次借出即抛 CommunicationsException: Connection is closed 或 PooledConnection is invalid。
安全做法是：将 maxLifetime 设为数据库 wait_timeout 的 70%～90%，并留出网络波动余量。例如 MySQL wait_timeout=3600（1 小时），则设 maxLifetime=2520000（42 分钟）。
- Oracle 的
sqlnet.expire_time机制类似，需同步校准maxLifetime - HikariCP 的
maxLifetime=0表示禁用生命周期检查，等同于放任连接老化，生产环境禁用 - 连接泄漏检测（
leakDetectionThreshold）不能替代maxLifetime，前者查“未归还”，后者防“已失效”
borrowTimeout 不是超时兜底，而是并发保护开关
borrowTimeout（如 HikariCP 的 connection-timeout）常被误认为“等待连接的最大时间”，实际它是线程在连接池队列里排队的上限。一旦超时，直接抛 SQLTimeoutException，不会触发重试或降级逻辑。
这个值必须结合业务 RT 和连接池容量设计：若平均查询耗时 50ms，连接池大小为 20，突发流量使排队线程达 50 个，则平均排队时间 ≈ (50−20) × 50ms = 1500ms。此时 borrowTimeout 若设为 1000ms，30% 请求会立即失败。
- 建议设为 P95 业务 SQL 耗时的 2～3 倍，而非固定 30s
- 设得太小（如 100ms）会导致大量请求因排队失败，掩盖真实瓶颈
- 设得太大（如 30s）会让线程长时间卡在池队列，加剧线程饥饿，甚至触发 Tomcat 线程池满
事务内禁止手动 close() 连接句柄
JDBC 规范要求：事务上下文中的 Connection.close() 必须由连接池接管，而非业务代码显式调用。Spring 的 @Transactional、MyBatis 的 SqlSession、JPA 的 EntityManager 都依赖此约定。
手动 close() 会提前将连接归还池中，但事务尚未提交/回滚，导致后续 SQL 报 SQLException: Connection is closed 或更隐蔽的数据不一致（如部分语句执行但未提交）。
- 检查所有
try-with-resources是否包裹了Connection——这是典型反模式 - 使用 Druid 时，开启
removeAbandonedOnBorrow=true可回收疑似泄漏的连接，但无法修复事务中断 - 连接池日志中出现
abandoned connection提示，往往就是业务层过早 close 导致
maxLifetime 与数据库参数的错位、borrowTimeout 对线程模型的影响、事务中连接生命周期的归属权，这三个点最容易在线上静默引发雪崩。 
