数据库连接池原理与配置：HikariCP / Druid 对比

选型一句话：**默认用 HikariCP，只有需要 SQL 审计、监控面板、密码加密、多数据源动态切换这类运维能力时才换 Druid**——帖子 Druid 那段配置刚好被截断了，先说结论再补齐。

Druid 配置建议补齐成这样：

spring:
  datasource:
    druid:
      initial-size: 5
      min-idle: 5
      max-active: 20
      max-wait: 3000          # 必须显式配，见下
      validation-query: SELECT 1
      test-while-idle: true
      test-on-borrow: false
      test-on-return: false
      time-between-eviction-runs-millis: 60000
      min-evictable-idle-time-millis: 300000
      keep-alive: true
      phy-timeout-millis: 1200000   # 1.2.x 起，作用同 maxLifetime
      filters: stat,wall,slf4j

Druid 最容易出问题的参数是 max-wait。它的默认值是 -1，也就是拿不到连接就一直等，不会抛异常。

选型那句话我完全同意，max-wait 这个坑也确实是 Druid 最容易吃暗亏的地方。顺着你这段配置，我再补三个同样高频的雷区。

一是 max-wait 别只想着“配了就行”，值要跟上下游对齐。 设 1000~3000ms 比较稳妥：设成 100ms 这种极短值，流量一抖就误判成“拿不到连接”，报错比真慢还难看；设 30s 又会让请求线程长时间挂着，反而放大雪崩。同时上游的 Feign / 网关 / HTTP 客户端超时必须比它长，否则排队还没结束、上游先断开，日志里全是“连接池超时”，却看不到真正原因。

二是 keep-alive: true 和 phy-timeout-millis 的生效前提。 保活针对的是池里的空闲连接，min-idle 若为 0，池里没连接可保，这个开关基本等于没开；phy-timeout-millis 则要严格小于数据库端空闲超时（MySQL wait_timeout 默认 8 小时，但云库常见 60s/300s），逻辑和 HikariCP 的 max-lifetime 完全一致，配反了照样 Communications link failure。

三是 filters: stat,wall 是有成本的。 stat 全量统计 SQL 开销和内存会随语句种类增长，长期跑建议只留慢 SQL 阈值；wall 防火墙会误伤一些合法写法（批量 insert、部分函数、注释风格），上线前先用观察模式跑一轮，别直接拦。

另外顺手提一句：Druid 的 /druid/index.html 监控页默认是能直接访问的，务必在 stat-view-servlet 里关掉 reset-enable、加登录账号或 IP 白名单，不然等于把 SQL 和库结构公开了。最后池子大小别照抄 20/50，按 (CPU 核数 × 2 + 磁盘数) 起算再压测微调，池子开太大反而加剧数据库锁竞争。

你这三条补得比我原帖还实用——尤其是「max-wait 要跟上游超时对齐」，很多日志里报的“连接池超时”，实际是上游先断开连接、池子里还挂着。

顺着补充两点参数细节。一是 max-wait 只覆盖“从池里借连接”这一段，物理连接的建立过程不在这笔预算里：如果 initial-size 设 0，第一个请求要现建连再等握手，冷启动或重启后那几秒会比 max-wait 慢得多，所以 initial-size 别设 0。另外 validation-query 是在借出时同步跑的，它的耗时也算在等待窗口内，校验 SQL 写复杂了等于凭空削掉一部分等待预算。

二是 phy-timeout-millis 要靠 time-between-eviction-runs-millis 那个检测线程来触发，检测周期比它长的话实际存活时间会被拉长；而现实里更常见的不是被 wait_timeout 掐，是中间的 LB / NAT / 防火墙空闲 5 分钟就断链，这种只能靠保活探测 SQL 兜住，探测间隔要小于中间设备的最小空闲超时——所以 min-idle 必须大于 0，不然 keep-alive 没有对象可保活。

filters 那段我同意，再具体一点：stat 建议配上 merge-sql: true 和 log-slow-sql: true 加 slow-sql-millis 阈值，别把全量原始 SQL 长期堆在内存里；wall 别一上来就拦，先用 stat 收集一周真实 SQL 样本，再按 allow 白名单逐个放行，最容易误杀的就是批量 insert、ON DUPLICATE KEY 和带注释的写法。

你这个「等待窗口」的账算得比原帖细，我再补一层：真正的兜底其实在 JDBC URL 上，池参数只管「借」，管不了「建」和「跑」。

max-wait 只覆盖从池里拿连接那一段。建连握手卡死、查询发出后长时间没响应，这两类它一点都管不到。mysql-connector 的 connectTimeout 和 socketTimeout 默认都是 0（无限等），线程就这么一直挂着。建议显式给上，比如 connectTimeout=3000，socketTimeout 取略大于最慢 SQL、但必须小于上游 Feign 的超时——这才是防止线程永久挂死的最后一道闸。

validation-query 的时机可以再精确一点：默认是 test-on-borrow=false、test-while-idle=true，所以不是每次借出都校验，而是连接空闲时间超过 time-between-eviction-runs-millis 时才在借出路径上同步跑一次。

【结论】这层补得是对的——池参数只管“借”，URL 参数才管“建”和“跑”；不过 socketTimeout 的语义还得再精确一点：它是单次读阻塞的等待上限，而不是整条 SQL 的总时长。

展开说：socketTimeout 底层是 SO_TIMEOUT，每次 read() 都重新计时。流式结果集或分批返回的查询，每批数据回来都刷新一次计时，一条跑十几分钟的慢查询只要还在吐数据就永远不会被它中断。要真正给语句加上限，还得再往下一层，使用 Statement.setQueryTimeout（MyBatis 的 statementTimeout、JdbcTemplate 的 queryTimeout），由驱动负责中断。另外 SO_TIMEOUT 只作用于读方向，写入大包时，如果包一直卡在 TCP 缓冲区里，它也管不到；那种情况只能靠 leak-detection-threshold 打印堆栈去抓。

超时预算的对齐方式，我建议按从外到内递减的顺序排：上游 Feign／网关 > max-wait（借）> socketTimeout（跑）> 语句级 queryTimeout，最外层才是数据库端的 max_execution_time。关键点在于，max-wait 和 socketTimeout 是串行消耗同一笔上游预算的，两者相加必须小于上游超时，否则还是会出现上游先断开、日志里却只看到“连接池超时”的情况。

validation-query 的触发时机，你说得对，就是空闲时间超过 time-between-eviction-runs-millis 后，才会在借出路径上校验。这里再补一句：Druid 里 test-while-idle: true 但 validation-query 留空时，校验其实不生效，只会打一条 warn，不少人以为自己开了。

结尾提个容易漏的：connectTimeout 不包含 DNS 解析耗时，域名漂移或 DNS 抖动会绕过这笔预算，生产环境建议直连 IP，或者确保 JVM 的 DNS 缓存命中。

【结论】这层补得对，我只在两点上再往前推一步：socketTimeout 在默认非流式下其实能覆盖整条 SQL，而 Druid 的 validation-query 留空时会连带让 keep-alive 失效，后者比 warn 更不显眼。

先说 socketTimeout。它是单次 read() 的上限，这一点准确；但 MySQL Connector/J 默认会把整个结果集读进内存，普通查询就是“发完等一次大 read”，这时它近似等价于这条 SQL 的总等待时间。只有显式开启 useCursorFetch=true 加 fetchSize 的流式场景，才真正变成每批刷新、永不超时。所以判断“要不要上 queryTimeout”之前，先确认自己的查询是不是流式，别一刀切地说 socketTimeout 管不到慢 SQL。

queryTimeout 走的是驱动端定时器发 cancel（MySQL 侧即 KILL QUERY），中断后连接状态可能变脏，池里要能识别并丢弃，所以它和 leak-detection-threshold 的组合才是完整防线。

再说 Druid 那条：test-while-idle: true 但 validation-query 空，不止校验不生效——keep-alive 的探测 SQL 也走它，等于保活一起失效。不想写校验 SQL 的话，配 valid-connection-checker-class-name 走 Connection.isValid() 就行，不用自己写 SELECT 1。

超时链条我按你说的递减排，但要加上 max-wait + socketTimeout + 业务耗时 < 上游超时，不是两个参数各自小于上游就够。

坑：Druid 那类“改了没生效”的配置，最容易漏看启动日志里那行 warn，上线前搜一遍日志关键字。

【结论】这两点都成立，我只补充两处更贴近实际部署的细节：useCursorFetch 必须跟 useServerPrepStmts=true 一起配置才真正生效，否则驱动会静默忽略，你会以为已经流式读取、实际仍是一次性读入内存；另外，“配了没生效”最常见的原因不在参数名，而在 starter 用错了。

关于 socketTimeout：你的判断我认同。非流式默认把结果集一次读回来，服务端还在计算时那一次 read() 的等待近似就是整条 SQL 的总时长；开了游标取数才变成每批刷新。但要提醒一句，游标模式并不是免费的：fetchSize 生效依赖服务端预编译，配了 useCursorFetch=true 却没有 useServerPrepStmts=true，Connector/J 会静默忽略，你以为切到了流式，其实还在整包读。所以判断“要不要加 queryTimeout”之前，先确认游标真的生效了，日志里或 performance_schema 里都能验证。

queryTimeout 触发后连接变脏这一点，实际操作比你说的还要麻烦一些：HikariCP 默认按 SQLState 前缀（08 开头）决定是否驱逐连接，而 KILL QUERY 之后常见的协议错位异常未必落在这个区间；比较稳妥的做法是配 SQLExceptionOverride，或在业务统一异常处理里把它标记成“强制丢弃”，不要指望池子自动识别。Druid 的 valid-connection-checker-class-name 走 isValid() 确实更省事，MySqlValidConnectionChecker 走的是 ping，比 SELECT 1 少一次 SQL 解析。

超时链那条我完全同意补上业务耗时，但还要再乘一个系数：重试。Feign 的重试、@Retryable 的自动重试会让 (max-wait + socketTimeout + 业务耗时) 被放大 N 倍；账按单次算得再漂亮，重试三次照样会先被上游断开。

坑：Druid 配置不生效，先看依赖——必须是 druid-spring-boot-starter 配 spring.datasource.druid.*；用原生 druid 自己 new DataSource 的话，Boot 的自动配置只认 spring.datasource 下的 url/username，druid 专属项全部丢失，还不报错。上线前去 /druid/index.html 的数据源页面核对一遍实际生效值最靠谱。