3. 连接池基础概念：连接池的作用、常见连接池对比
在数据库访问层，建立 TCP 连接、完成握手认证、分配会话资源通常需要 20–100 ms。如果每次 SQL 执行都新建连接，高并发下系统吞吐会急剧下降。连接池的核心思路是：复用长连接，避免频繁创建与销毁，从而降低延迟、控制并发、保护后端数据库。
3.1 连接池的核心作用
| 作用维度 | 说明 | 对慢查询场景的价值 |
|---|---|---|
| 连接复用 | 预先创建一组连接，请求时借出，归还后重用 | 消除每次查询的连接建立开销，让慢查询本身成为唯一瓶颈 |
| 并发控制 | 通过 maximumPoolSize 限制同时执行的 SQL 数量 |
防止慢查询堆积时打爆数据库连接数，形成雪崩 |
| 连接健康检测 | 定期发送心跳 SQL（如 SELECT 1）剔除失效连接 |
避免慢查询拿到已断开的连接，导致额外重试与超时 |
| 等待队列 | 连接耗尽时，请求进入阻塞队列，超时后抛出异常 | 配合熔断降级，快速失败而非无限等待 |
| 统计与监控 | 暴露活跃连接数、等待线程数、连接获取耗时等指标 | 为慢查询调优提供数据支撑，定位连接瓶颈 |
关键认知：连接池不是越大越好。过大的连接池会让数据库上下文切换加剧，反而增加慢查询响应时间。最佳实践是
maximumPoolSize = (CPU核心数 × 2) + 有效磁盘数，再结合实际压测微调。
3.2 连接池工作流程
下图展示了一个典型连接池在慢查询场景下的请求生命周期：
实践要点：连接池的
connectionTimeout 应小于应用层的超时时间，确保连接池先抛出异常，触发熔断降级逻辑，而不是让应用线程一直阻塞。
3.3 主流连接池对比
Java 生态中最常用的三款连接池：HikariCP、Druid、Tomcat JDBC。它们在性能、监控、功能侧重上差异明显，选型需结合团队运维能力与场景需求。
| 对比维度 | HikariCP | Druid | Tomcat JDBC |
|---|---|---|---|
| 性能 | 极优（字节码精简，无锁集合） | 良好（内置 Filter 链有额外开销） | 良好（Tomcat 原生，轻量） |
| 监控能力 | 基础（通过 JMX 暴露指标） | 强大（SQL 统计、慢查询日志、Web 界面） | 基础（需自行扩展） |
| 连接泄漏检测 | 支持（leakDetectionThreshold） |
支持（removeAbandoned 机制） |
不支持原生 |
| 慢查询拦截 | 不支持原生 | 支持（SlowSqlMillis + 日志） |
不支持原生 |
| SQL 防火墙 | 无 | 支持（防注入、黑白名单） | 无 |
| 配置复杂度 | 低（参数少，默认值合理） | 中（参数多，需调优） | 低（与 Tomcat 配置一致） |
| Spring Boot 默认 | 是（2.0+ 默认） | 需手动引入 | 需手动引入 |
| 社区活跃度 | 高（Brett Wooldridge 维护） | 高（阿里开源，中文文档丰富） | 中（Apache 社区） |
3.4 选型建议
- 追求极致性能、监控需求简单：选 HikariCP。它是 Spring Boot 默认连接池，参数精简，适合微服务场景。
- 需要慢查询拦截、SQL 审计、防火墙：选 Druid。其内置的慢查询日志和 Web 监控页面在慢排查场景中非常实用。
- 已有 Tomcat 容器、不想引入额外依赖：选 Tomcat JDBC。性能足够，但缺少高级监控功能。
避坑提醒：Druid 的
removeAbandoned 机制虽然能回收泄漏连接，但可能误杀长时间执行的慢查询。在慢查询调优期间，建议将 removeAbandonedTimeout 设为一个较大的值（如 300 秒），或直接关闭该功能，避免连接被强制回收导致事务中断。
3.5 连接池参数与慢查询的关联
连接池参数直接影响慢查询场景下的系统行为。下表列出关键参数及其调优方向：
| 参数 | 默认值（HikariCP） | 慢查询场景调优建议 |
|---|---|---|
maximumPoolSize |
10 | 根据 CPU 核心数和慢查询并发数调整，避免过大导致数据库负载飙升 |
connectionTimeout |
30000 ms | 建议设为 5000–10000 ms，配合熔断器快速失败 |
idleTimeout |
600000 ms | 保持默认或适当缩短，避免空闲连接占用数据库资源 |
maxLifetime |
1800000 ms | 建议小于数据库的 wait_timeout，防止连接被服务端断开 |
leakDetectionThreshold |
0（关闭） | 设为 60000 ms，帮助定位慢查询是否由连接泄漏引起 |
核心原则：连接池是数据库的“流量阀门”。在慢查询场景下，通过合理设置
maximumPoolSize 和 connectionTimeout，可以控制进入数据库的请求量，为熔断降级争取判断时间，避免系统被慢查询拖垮。