Druid 连接池配置与调优实战三类场景一次配到位【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址: https://gitcode.com/gh_mirrors/druid/druid凌晨三点告警弹出一条 Druid 连接超时 记录等待获取连接超过 60 秒接口大面积报错。排查后发现问题不在 SQL而在连接池参数配得不对。本文从机制讲起给出三类场景的 Druid 连接池调优配置与验证方法。先看机制连接在池里是怎么流转的可以把连接池想象成图书借阅馆数据库连接是架上的书应用借走一本执行 SQL调用 close 就是还——书并没有消失只是在书架和读者之间流转。馆里还有一位值班管理员后台驱逐线程他定期抽查归还的书是否已经变质连接有效性验证把坏书淘汰掉并保证书架上始终保有基础存量的书。连接池的日常运转由两组数驱动一组是数量——开多少、等多久、留多少默认值都定义在 DruidAbstractDataSource.java 里另一组是质量——连接借出前是否还可用、谁来检查由 ValidConnectionChecker.java 接口及各数据库实现类完成。建立这个模型再看任何参数名都不会迷路。按场景做 Druid 参数配置三套配置小流量服务少而稳的基线配置小流量服务不必激进核心是别开太多、也别归零留少量常备连接减少翻台同时给等待设一个熔断值避免无限阻塞。参数默认值为什么关注它initialSize0启动时创建的连接数可给个 1~2 的小值minIdle0空闲保底量建议与 initialSize 对齐maxActive8连接上限低流量下默认值往往就够用maxWait-1无限等待务必显式设置它是获取连接的最后一道闸testWhileIdletrue默认开启后台线程负责验证空闲连接timeBetweenEvictionRunsMillis60000后台检查间隔60 秒起步理由低流量场景的瓶颈不是连接数量而是稳定——minIdle 保活减少用完即销毁的翻台maxWait 则把无限阻塞变成快速失败报错。# 小流量服务基线 druid.initialSize2 druid.minIdle2 druid.maxActive10 druid.maxWait5000 druid.testWhileIdletrue druid.timeBetweenEvictionRunsMillis60000 druid.minEvictableIdleTimeMillis1800000高并发读写拉上限、预热连接、复用语句QPS 上来之后关键动作有三个容量上限顶得住峰值、启动时预热让首批请求不付出建连成本、重复 SQL 复用预处理语句降低 prepare 开销。参数默认值为什么关注它maxActive8容量按实测并发与数据库连接配额定不是拍脑袋initialSize0预热启动即建好一批避免高峰期现造连接asyncInitfalse异步初始化池初始化不卡住应用启动poolPreparedStatementsfalse打开后本地缓存 Statement重复 SQL 免 preparemaxPoolPreparedStatementPerConnectionSize10每连接缓存量按高频 SQL 条数放大sharePreparedStatementsfalse跨连接共享进一步摊薄 prepare 成本理由建连与 prepare 都是随 QPS 线性上涨的开销预热 缓存是高并发下两笔最划算的投入。# 高并发读写 druid.initialSize10 druid.maxActive50 druid.minIdle10 druid.maxWait3000 druid.asyncInittrue druid.poolPreparedStatementstrue druid.maxPoolPreparedStatementPerConnectionSize32 druid.sharePreparedStatementstrue druid.connectionPropertiesdruid.stat.mergeSqltrue;druid.stat.slowSqlMillis500提醒一句maxActive 不要拍脑袋它的总和不能超过数据库侧的连接配额否则超时会被压到数据库端再反噬回来。长事务防泄漏把借出去不还的连接收回来最棘手的泄漏是代码忘记 close连接被永久占用几天后池子被占满。Druid 提供兜底——检测到占用超过阈值的连接就强制回收还能打印创建时的堆栈让你直接定位泄漏点。参数默认值为什么关注它removeAbandonedfalse泄漏回收总开关removeAbandonedTimeoutMillis300000借太久的判定阈值要比最长事务留足余量logAbandonedfalse强制回收时打印堆栈是找到泄漏点的关键testWhileIdletrue连接有效性基线保障保持开启理由阈值若小于业务里最长的正常事务正常业务会被误伤进强制回收所以留足余量是这条配置的命门。# 长事务防泄漏 druid.removeAbandonedtrue druid.removeAbandonedTimeoutMillis180000 druid.logAbandonedtrue druid.testWhileIdletrue druid.timeBetweenEvictionRunsMillis60000Druid 监控页面看哪几个数 配置完不要猜看数。Druid 的监控页由 StatViewServlet.java 提供接入方式见仓库文档 doc/monitoring-guide.md重点盯四个数指标健康状态不健康说明什么ActiveCount活跃连接数明显低于 maxActive长期顶格 → 容量不足或连接被长时间占用WaitThreadCount等待线程数几乎恒为 0持续大于 0 → 池接近耗尽超时前兆ErrorCount错误数保持 0增长 → 查数据库可用性与验证配置慢 SQL 次数低位平稳持续上涨 → 问题在 SQL 而非池参数判断方法很简单先看连接类指标判断池够不够再看慢 SQL 判断SQL 快不快。若活跃数平稳而响应时间仍抖动调优方向就该从池参数转向数据库本身别再拧连接池的螺丝了。排坑清单Druid 连接超时、内存泄漏与性能波动现象定位线索处理动作Druid 连接超时抛出 GetConnectionTimeoutExceptionActiveCount 顶格、WaitThreadCount 0数据库侧存在慢查询调大 maxActive优化长事务 SQL开启 removeAbandoned 回收调小 maxWait 快速失败疑似 Druid 内存泄漏堆持续增长、GC 频繁activeCount 回不到基线logAbandoned 开启后能看到创建堆栈统一 try-with-resources 关闭资源按堆栈修泄漏点确认 ResultSet/Statement 均已 close性能波动偶发响应尖刺慢 SQL 计数间歇性增长或建连次数突然上冲冷连接集中创建提高 minIdle 保活保持 testWhileIdle 开启针对慢查询补索引写在最后数量开多少、等多久、质量是否验证、安全泄漏回收三组数是 Druid 连接池配置的全部骨架。按场景落参数小流量求稳高并发求预热与缓存长事务求回收与留痕。配完用监控页四个数验证先分清池满还是SQL 慢再决定拧哪颗螺丝。延伸阅读连接池参数速查 doc/connection-pool-guide.md、监控接入指南 doc/monitoring-guide.md以及核心实现所在的 pool 包。【免费下载链接】druid阿里云计算平台DataWorks(https://help.aliyun.com/document_detail/137663.html) 团队出品为监控而生的数据库连接池项目地址: https://gitcode.com/gh_mirrors/druid/druid创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
