干后端时间长了都会碰到这么个场景应用时不时报获取连接超时DBA那边说数据库负载不高但你翻日志死活找不到具体是哪个接口拖慢了。我去年排查一个订单服务时也是这样最后靠数据库连接池Druid的监控面板一眼锁定了一条慢SQL才发现是某个统计查询没走索引。从那以后我基本每个项目都会把Druid接上并不全是因为它性能最强而是它的可观测性实在太有用。这篇文章就围绕数据库连接池Druid展开它到底解决了什么问题、核心参数怎么配才合理、监控面板怎么用、以及我在实际项目中踩过的坑。不管你是刚接触连接池概念的新手还是已经在用Druid想深入调优的开发者应该都能从里面找到点能直接拿去用的东西。1. 连接池到底解决了什么问题1.1 一次数据库连接的成本有多高你可能没算过没有数据库连接池的时候你写的代码可能是这样每次要查数据现场DriverManager.getConnection()建立一条连接用完再close()关掉。这在开发和测试环境没问题但一到生产就出事情。为什么因为一次物理连接的开销很多时候比SQL执行本身还大。我抽象一下这个过程你自己判断成本TCP三次握手建立socket通道这要经过网络栈往返MySQL服务端要为新连接分配线程、初始化会话状态连接建立之后客户端和服务端还要做权限校验、字符集协商、事务隔离级别设置首次这一步之后后续每条SQL还要走SQL解析、优化器生成执行计划、真正执行、返回结果。这串动作里真正费时间的往往不是SQL执行而是前面那串握手和初始化。有人专门测试过内网环境下一次完整的建连大约需要 30ms 到 80ms而一条简单的索引查询可能只需要 1ms 到 2ms。这意味着如果没有连接池你的应用有超过 90% 的时间花在了“准备干活”而不是“干活”上这在互联网应用里是不可接受的。就好比你每天都去食堂吃饭结果食堂每天现从种菜开始。连接池做的事情很简单提前把几百个连接建好放在池子里谁要用就拿走用完还回来而不是现场重新种菜。1.2 Druid在连接池家族里的定位不止是池子Java生态里连接池有好几个DBCP、C3P0、HikariCP、Druid。很多新手会问都是连接池选哪个区别很大吗老实说有区别但这些连接池的核心机制是一样的都是用一个池子来复用物理连接控制并发数统一管理连接生命周期。Druid真正不一样的地方在于三个点。第一是监控能力。它内置了非常完整的统计体系能统计每个SQL的执行次数、耗时、返回行数、并发数甚至能记录慢SQL明细。这一点在定位线上问题上价值极大后面我会专门讲。第二是Filter链机制。Druid把连接池的各个关键节点设计成了可插拔的过滤器官方自带了一批很有用的Filterstat负责统计wall负责SQL防火墙slf4j负责日志输出。你想扩展自己的逻辑也很容易写一个自己的Filter实现对应接口就行侵入性很小。第三是SQL防注入能力。wallFilter内置了一套完整的SQL语法解析器可以识别并拦截常见的注入模式也可以配置白名单机制限制只能执行某几类SQL。这对安全合规要求高的系统特别友好。性能上它的极致吞吐量确实不如HikariCP但差距很小多数业务系统根本感知不到。现实选择逻辑往往是如果你需要在线排查慢SQL、需要监控连接池运行情况、需要对SQL做安全管控Druid是最省事的方案。如果你追求极端性能和零依赖项目也不复杂那HikariCP更轻量。我现在个人的默认选择就是Druid除非项目的依赖和包体积卡得非常死。2. Druid核心参数配置照着抄就行2.1 从连接池的工作流程图解核心参数配置Druid之前你把连接池想象成一个图书馆的座位管理系统。图书管理员连接池在开馆前会预留一批空座位initialSize同时保证馆内某个最低数量的座位一直空着minIdle但最多只能坐这么多人maxActive。有人来占座时管理员最多会让他等多久maxWait超过这个时间就直接让他改天再来抛异常。学生来上自习时管理员隔一段时间就巡逻一次timeBetweenEvictionRunsMillis看看哪些座位一直空着且空了很久minEvictableIdleTimeMillis可以收走桌子上的书本清理出来物理关闭连接。学生坐下去之前管理员要检查一下桌椅是否还能用testWhileIdle、testOnBorrow发现损坏的及时修复免得学生坐上去再摔一跤。对应到Druid参数你大概是这样一套常用的配置Spring Boot配置文件中spring: datasource: druid: initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false keep-alive: trueinitial-size连接池启动时预创建的连接数。注意它和min-idle的区别initial-size只管启动那一刻的初始化min-idle是池子长期维持的下限。因为建连很贵启动时热身一批连接可以避免刚上线时被突发流量打穿。max-active池子里最多同时被借出的连接数。这个值不是越大越好它本质上是数据库并发能力的上限。MySQL默认连接数是151你如果max-active配了200加上其他应用也连同一个库很容易就把数据库连接数打满。max-wait拿不到连接时的最大等待毫秒数。配太短容易频繁报wait millis 60000类错误配太长用户请求会长时间挂起。一般建议30秒到60秒之间超过这个值基本说明连接被占满或者后端出问题了与其让请求傻等不如快速失败暴露问题。test-while-idle和test-on-borrow这两个都涉及连接可用性检测但角度不同。test-while-idle是后台清理线程在巡检时发现的空闲连接顺手验证一下test-on-borrow是每次从池子里借出连接时都先验证一遍。前者开销小后者更安全但每条连接借出都要额外跑一次SELECT 1性能损耗明显。生产环境我一般只开test-while-idle不开test-on-borrow。keep-alive这个参数非常重要配合min-idle使用。当池子里连接数低于min-idle时keep-alive会让后台线程主动补充新连接。它跟min-evictable-idle-time-millis不同后者是“清理过期的空闲连接”前者是“保证池子至少有多少条可用连接”。两者一起用就能覆盖“空闲回收”和“最低水位保持”两种需求。2.2 核心参数的计算思路结合业务QPS参数不能拍脑袋定。很多团队直接把网上某个模板复制进去结果生产环境出问题。我一般用这个粗粒度估算方式假设你的系统平均响应时间在 200ms 以内单条SQL平均耗时约 10ms系统目标峰值 QPS 是 1000单次请求平均执行 3 条SQL。那么同时并发执行的SQL条数大约是 1000 × 3 × 0.01 30 条也就是说数据库需要的并发连接数在 30 左右。这时max-active配 30 到 40 是比较合理的区间。再留一点Buffer最终我往往取 50。这里有个经验值max-active通常取“预估并发SQL数”的1.2到1.5倍。配太小会导致请求排队甚至报错配太大会给数据库带来无谓的线程调度压力还容易触发数据库端连接数限制。min-idle则根据低峰流量来定。如果是典型的白天高晚上低的业务min-idle配max-active的1/4到1/5就够了如果是不分时段的持续流量可以把min-idle直接配成max-active避免频繁创建和回收连接。还有个细节我提一下连接池参数不是设置完就不动了。上线后要看监控面板里的activeCount和waitCount如果activeCount长期贴着max-active说明连接不够用要考虑扩容或优化SQL如果waitCount经常大于0说明经常有人排队等连接要么调大max-active要么优化SQL缩短占用时间。2.3 慢SQL统计与日志接入生产必备Druid想要输出统计信息必须把对应的Filter打开。最常见的配置是spring: datasource: druid: filters: stat,wall,slf4j connection-properties: druid.stat.mergeSqltrue;druid.stat.slowSqlMillis500filters里三个Filter各司其职stat负责统计所有执行过的SQLwall负责SQL防火墙slf4j负责把SQL执行日志打到日志文件里。druid.stat.slowSqlMillis500的意思是把执行耗时超过500毫秒的SQL标记为慢SQL。这个阈值要看业务场景设定交易类系统我觉得500ms很合理报表分析类系统可以放宽到1秒但如果你做的是支付接口可能200ms就算慢。druid.stat.mergeSqltrue是个容易被忽略的好配置。默认情况下Druid按SQL文本原样统计比如WHERE id 1和WHERE id 2会被当成两条SQL统计结果碎片化严重。开启mergeSql后Druid会将带参数的SQL整合成一条模板统计出聚合耗时。这样在监控面板里你看到的就不是几十条长得差不多的SQL而是一条SELECT * FROM orders WHERE id ?的总执行次数和总耗时直观很多。slf4j Filter的作用是打日志。开了这个Filter后Druid会把执行的SQL、执行参数、耗时信息输出到日志系统。注意这里有过量日志刷盘的风险高峰期每秒可能打印几千条SQL需要合理配置日志级别和异步Appender否则日志I/O会成为新的瓶颈。我自己的方式是单独给SQL日志建一个Logger设置独立文件并按天滚动然后定期清理。3. 监控面板和Filter机制Druid能成为首选的关键3.1 StatViewServlet几分钟搭好一个监控页面Druid自带的监控面板是一个非常直观的运维工具。在Spring Boot里接入也很简单配置一个Servlet就可以了。一个基础配置长这样Configuration public class DruidMonitorConfig { Bean public ServletRegistrationBeanStatViewServlet statViewServletRegistrationBean() { ServletRegistrationBeanStatViewServlet registration new ServletRegistrationBean(new StatViewServlet(), /druid/*); registration.addInitParameter(loginUsername, admin); registration.addInitParameter(loginPassword, admin123); registration.addInitParameter(resetEnable, false); return registration; } Bean public FilterRegistrationBeanWebStatFilter webStatFilterRegistrationBean() { FilterRegistrationBeanWebStatFilter filter new FilterRegistrationBean(new WebStatFilter()); filter.addUrlPatterns(/*); filter.addInitParameter(exclusions, *.js,*.css,/druid/*); return filter; } }配置好之后启动应用访问/druid/index.html输入账号密码就能看到监控页面。面板上有几个Tab我最常用的是“数据源”和“SQL监控”。“SQL监控”页面会展示上面提到的合并后的SQL列表每一条都有执行次数、总耗时、最大耗时、返回行数等指标。按总耗时排序基本就能把系统的Top慢SQL拉出来。我前面提到的那个精准定位慢SQL的场景就是在这个页面里完成的。另外两个值得看的指标是activeCount和waitCount。activeCount代表当前被借走的连接数如果长期接近max-active说明连接不够用waitCount表示等待获取连接的次数这个数字快速增长往往意味着连接池已经打满请求在排队。这两个指标能从数据源页面直接看到不需要额外写监控代码。顺带提醒一句生产环境一定要给监控页配账号密码并且不要用弱密码。这个页面暴露的信息非常详细包括SQL文本、连接创建次数、事务耗时等一旦泄露给攻击者相当于把数据库的底牌全亮出来了。3.2 wall FilterSQL防火墙的正确打开方式wallFilter是Druid的另一个硬核能力。它内置了一个完整的SQL语法树解析器能把要执行的SQL解析成语法树然后根据配置的规则做判断符合规则才放行。基础配置一般是spring: datasource: druid: wall: enabled: true multi-statement-allow: false none-base-statement-allow: false condition-and-or-allow: false这几个参数的解释multi-statement-allow控制是否允许一次执行多条SQL。为false时直接拦截类似SELECT 1; DROP TABLE users;这种拼接注入。none-base-statement-allow为false时非标准的SQL语句不在基本语句类型列表里的会被拒绝执行。condition-and-or-allow为false时不允许多个AND/OR条件混用这能挡住不少重逻辑的注入尝试。配置好之后可以主动做个小验证往接口传一个 OR 11这类参数观察日志Druid会输出sql injection相关的拦截警告SQL本身不会真正执行。这里要特别说明一点wall是防注入的辅助手段不是替代SQL预编译。最佳姿势是两层都做代码层统一使用预编译语句占位符传递参数wall作为兜底拦截那些因为历史原因或框架漏洞绕过预编译的SQL。只靠防火墙不写预编译早晚要出事。4. 实操过程中踩过的坑与排查思路4.1 MySQL 8小时断开连接问题keepAlive能救但不万能这是一个经典场景不少老项目都遇到过应用跑了一晚上第二天早上一来业务报一堆Communications link failure或Connection is not available重启应用就好过一阵又复发。背后原因是MySQL服务端有wait_timeout参数默认8小时。如果一条连接连续空闲超过这个时间服务端就会主动把它断掉。但连接池客户端并不知道这条连接已经死了下次从池子里借出这条连接执行SQL时才发现连接早就不可用于是报错。Druid解决的思路分两层。第一层是test-while-idle加validation-query后台线程在巡检空闲连接时自动检测发现失效就踢出池子并新建一条补上。第二层是keep-alive当池子里连接数低于min-idle时keepAlive线程会主动探测并补充连接确保池子里的连接不长期闲置。但有一个坑如果你把min-idle设为0那么即使开了keep-alive空闲时池子里可能一条连接都不剩keepAlive也救不了你。想彻底解决8小时问题min-idle至少要有1到5让池子里始终有活连接在滚动心跳。还要提一个场景容器环境下Druid所在的Pod在做滚动发布时旧Pod的连接是没来得及归还的。如果应用优雅下线逻辑没处理好数据库这边会残留一堆Sleeping状态的连接长期不释放。这种问题在接入K8s后尤其常见需要同时处理连接池的回收和应用生命周期管理光靠连接池参数是不够的。4.2 连接被占满activeCount只增不减——连接泄露排查有一个让运维和开发都很头秃的问题系统运行一段时间后监控面板上的activeCount逐渐上涨到最后稳定在max-active附近数据库慢SQL不多但新请求却拿不到连接报GetConnectionTimeoutException。这个问题的真凶绝大多数是“连接泄露”代码里某个分支在获取连接后没有在finally块里归还或关闭导致连接被无限期占用。查起来很痛苦因为日志里看不出具体是哪个代码段没关闭连接。Druid提供了两个非常有用的配置来辅助排查spring: datasource: druid: remove-abandoned: true remove-abandoned-timeout: 180 log-abandoned: trueremove-abandoned: true开启后连接被借出超过remove-abandoned-timeout秒还没归还Druid会直接强制回收这条连接。log-abandoned: true会在回收时打印当时的调用栈信息这样你就能在日志里看到究竟是哪段代码、哪个方法拿走了连接不还。需要说明的是remove-abandoned是个双刃剑如果系统里有正常的长事务比如批量处理几百条数据开启后可能会被误杀直接中断事务导致数据不一致。所以我一般建议在排查阶段临时开启找到元凶修复后再关掉或者把remove-abandoned-timeout配得比正常最长事务耗时再长一些比如正常事务最长2分钟那就配300秒以上。排查连接泄露还有一招排查时先在监控面板记录activeCount的心跳数据再过半小时查看它是否下降。正常情况没有请求时连接应该归还到min-idle水位。如果activeCount一直挂着不动高度怀疑就是连接泄露。4.3 连接池初始化慢与首次访问卡顿这个问题不算严重但很多第一次用Druid的人会遇到。应用启动后第一次请求特别慢甚至超时但后续就正常了。原因有两方面一是initial-size配置了热身连接启动时创建这些连接本身就有开销二是首次请求时连接池还没完全热身要现场创建连接走一遍完整的建连过程。解决办法很简单应用启动后做一次简单的预热访问比如首页或者一个/health接口或者把initial-size调大。如果是K8s环境为应用配置就绪探针时把就绪判断做得严格一点确保连接池在接收流量前已经完成初始化。4.4 常见问题速查表现象可能原因排查与解决思路报wait millis 60000max-active打满连接被占满查看监控面板activeCount、waitCount判断是并发过高还是连接泄露凌晨/一夜后报连接失效MySQLwait_timeout回收了空闲连接开启keep-alivemin-idle建议设为大于0SQL监控页面空白filters没包含stat检查filters: stat是否配置确认连接池确实是Druid应用启动很慢initial-size过大或库网络较慢调整initial-size在Pod就绪探针中预热连接CPU飙升且连接频繁创建max-active反复在0和峰值间跳动增大min-idle避免连接反复创建销毁日志出现sql injection警告wall拦截了疑似注入SQL查看具体SQL文本确认是攻击还是误杀误杀则调整wall规则5. 关于连接池选型的一些真实体会文章到最后聊聊我这个几年实战下来对连接池选型的真实看法。如果你问的是“性能和功能到底怎么平衡”我个人已经把Druid当作Java后端项目的默认选择了极少因为“性能略微不如HikariCP”这个理由换掉它。因为在我的实际项目里绝大多数系统的瓶颈都不在连接池这十几毫秒的差距上而在线慢SQL、连接泄露、偶发连接不可用这类问题上。Druid的监控能力让这三类问题的定位成本低了一个量级这是性能表上几个百分点完全比不了的。但也有些场景我会选HikariCP比如项目本身极其轻量连监控面板都不需要或者对包体大小要求苛刻的网关类服务又或者公司已有统一的链路追踪体系连接池的监控跟业务监控重合度高。这时候Druid的完整功能反而成了多余的重量。最后再分享一个配置习惯如果你决定用Druid上线前一定要花半小时把手里的连接池参数过一遍至少确认这几项max-active和数据库最大连接数之间留有余量、max-wait不超过网关超时时间、initial-size和min-idle不为0、filters里stat和wall都开了。这五项我几乎每个项目都会复核也是Druid能稳定运行、不被数据库和网关双重殴打的底线配置。 
长河君 · 2026/10/17 3:03:09 · 阅读 1.2k 数据库连接池Druid实战：从参数配置到监控排查指南
干后端时间长了都会碰到这么个场景应用时不时报获取连接超时DBA那边说数据库负载不高但你翻日志死活找不到具体是哪个接口拖慢了。我去年排查一个订单服务时也是这样最后靠数据库连接池Druid的监控面板一眼锁定了一条慢SQL才发现是某个统计查询没走索引。从那以后我基本每个项目都会把Druid接上并不全是因为它性能最强而是它的可观测性实在太有用。这篇文章就围绕数据库连接池Druid展开它到底解决了什么问题、核心参数怎么配才合理、监控面板怎么用、以及我在实际项目中踩过的坑。不管你是刚接触连接池概念的新手还是已经在用Druid想深入调优的开发者应该都能从里面找到点能直接拿去用的东西。1. 连接池到底解决了什么问题1.1 一次数据库连接的成本有多高你可能没算过没有数据库连接池的时候你写的代码可能是这样每次要查数据现场DriverManager.getConnection()建立一条连接用完再close()关掉。这在开发和测试环境没问题但一到生产就出事情。为什么因为一次物理连接的开销很多时候比SQL执行本身还大。我抽象一下这个过程你自己判断成本TCP三次握手建立socket通道这要经过网络栈往返MySQL服务端要为新连接分配线程、初始化会话状态连接建立之后客户端和服务端还要做权限校验、字符集协商、事务隔离级别设置首次这一步之后后续每条SQL还要走SQL解析、优化器生成执行计划、真正执行、返回结果。这串动作里真正费时间的往往不是SQL执行而是前面那串握手和初始化。有人专门测试过内网环境下一次完整的建连大约需要 30ms 到 80ms而一条简单的索引查询可能只需要 1ms 到 2ms。这意味着如果没有连接池你的应用有超过 90% 的时间花在了“准备干活”而不是“干活”上这在互联网应用里是不可接受的。就好比你每天都去食堂吃饭结果食堂每天现从种菜开始。连接池做的事情很简单提前把几百个连接建好放在池子里谁要用就拿走用完还回来而不是现场重新种菜。1.2 Druid在连接池家族里的定位不止是池子Java生态里连接池有好几个DBCP、C3P0、HikariCP、Druid。很多新手会问都是连接池选哪个区别很大吗老实说有区别但这些连接池的核心机制是一样的都是用一个池子来复用物理连接控制并发数统一管理连接生命周期。Druid真正不一样的地方在于三个点。第一是监控能力。它内置了非常完整的统计体系能统计每个SQL的执行次数、耗时、返回行数、并发数甚至能记录慢SQL明细。这一点在定位线上问题上价值极大后面我会专门讲。第二是Filter链机制。Druid把连接池的各个关键节点设计成了可插拔的过滤器官方自带了一批很有用的Filterstat负责统计wall负责SQL防火墙slf4j负责日志输出。你想扩展自己的逻辑也很容易写一个自己的Filter实现对应接口就行侵入性很小。第三是SQL防注入能力。wallFilter内置了一套完整的SQL语法解析器可以识别并拦截常见的注入模式也可以配置白名单机制限制只能执行某几类SQL。这对安全合规要求高的系统特别友好。性能上它的极致吞吐量确实不如HikariCP但差距很小多数业务系统根本感知不到。现实选择逻辑往往是如果你需要在线排查慢SQL、需要监控连接池运行情况、需要对SQL做安全管控Druid是最省事的方案。如果你追求极端性能和零依赖项目也不复杂那HikariCP更轻量。我现在个人的默认选择就是Druid除非项目的依赖和包体积卡得非常死。2. Druid核心参数配置照着抄就行2.1 从连接池的工作流程图解核心参数配置Druid之前你把连接池想象成一个图书馆的座位管理系统。图书管理员连接池在开馆前会预留一批空座位initialSize同时保证馆内某个最低数量的座位一直空着minIdle但最多只能坐这么多人maxActive。有人来占座时管理员最多会让他等多久maxWait超过这个时间就直接让他改天再来抛异常。学生来上自习时管理员隔一段时间就巡逻一次timeBetweenEvictionRunsMillis看看哪些座位一直空着且空了很久minEvictableIdleTimeMillis可以收走桌子上的书本清理出来物理关闭连接。学生坐下去之前管理员要检查一下桌椅是否还能用testWhileIdle、testOnBorrow发现损坏的及时修复免得学生坐上去再摔一跤。对应到Druid参数你大概是这样一套常用的配置Spring Boot配置文件中spring: datasource: druid: initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false keep-alive: trueinitial-size连接池启动时预创建的连接数。注意它和min-idle的区别initial-size只管启动那一刻的初始化min-idle是池子长期维持的下限。因为建连很贵启动时热身一批连接可以避免刚上线时被突发流量打穿。max-active池子里最多同时被借出的连接数。这个值不是越大越好它本质上是数据库并发能力的上限。MySQL默认连接数是151你如果max-active配了200加上其他应用也连同一个库很容易就把数据库连接数打满。max-wait拿不到连接时的最大等待毫秒数。配太短容易频繁报wait millis 60000类错误配太长用户请求会长时间挂起。一般建议30秒到60秒之间超过这个值基本说明连接被占满或者后端出问题了与其让请求傻等不如快速失败暴露问题。test-while-idle和test-on-borrow这两个都涉及连接可用性检测但角度不同。test-while-idle是后台清理线程在巡检时发现的空闲连接顺手验证一下test-on-borrow是每次从池子里借出连接时都先验证一遍。前者开销小后者更安全但每条连接借出都要额外跑一次SELECT 1性能损耗明显。生产环境我一般只开test-while-idle不开test-on-borrow。keep-alive这个参数非常重要配合min-idle使用。当池子里连接数低于min-idle时keep-alive会让后台线程主动补充新连接。它跟min-evictable-idle-time-millis不同后者是“清理过期的空闲连接”前者是“保证池子至少有多少条可用连接”。两者一起用就能覆盖“空闲回收”和“最低水位保持”两种需求。2.2 核心参数的计算思路结合业务QPS参数不能拍脑袋定。很多团队直接把网上某个模板复制进去结果生产环境出问题。我一般用这个粗粒度估算方式假设你的系统平均响应时间在 200ms 以内单条SQL平均耗时约 10ms系统目标峰值 QPS 是 1000单次请求平均执行 3 条SQL。那么同时并发执行的SQL条数大约是 1000 × 3 × 0.01 30 条也就是说数据库需要的并发连接数在 30 左右。这时max-active配 30 到 40 是比较合理的区间。再留一点Buffer最终我往往取 50。这里有个经验值max-active通常取“预估并发SQL数”的1.2到1.5倍。配太小会导致请求排队甚至报错配太大会给数据库带来无谓的线程调度压力还容易触发数据库端连接数限制。min-idle则根据低峰流量来定。如果是典型的白天高晚上低的业务min-idle配max-active的1/4到1/5就够了如果是不分时段的持续流量可以把min-idle直接配成max-active避免频繁创建和回收连接。还有个细节我提一下连接池参数不是设置完就不动了。上线后要看监控面板里的activeCount和waitCount如果activeCount长期贴着max-active说明连接不够用要考虑扩容或优化SQL如果waitCount经常大于0说明经常有人排队等连接要么调大max-active要么优化SQL缩短占用时间。2.3 慢SQL统计与日志接入生产必备Druid想要输出统计信息必须把对应的Filter打开。最常见的配置是spring: datasource: druid: filters: stat,wall,slf4j connection-properties: druid.stat.mergeSqltrue;druid.stat.slowSqlMillis500filters里三个Filter各司其职stat负责统计所有执行过的SQLwall负责SQL防火墙slf4j负责把SQL执行日志打到日志文件里。druid.stat.slowSqlMillis500的意思是把执行耗时超过500毫秒的SQL标记为慢SQL。这个阈值要看业务场景设定交易类系统我觉得500ms很合理报表分析类系统可以放宽到1秒但如果你做的是支付接口可能200ms就算慢。druid.stat.mergeSqltrue是个容易被忽略的好配置。默认情况下Druid按SQL文本原样统计比如WHERE id 1和WHERE id 2会被当成两条SQL统计结果碎片化严重。开启mergeSql后Druid会将带参数的SQL整合成一条模板统计出聚合耗时。这样在监控面板里你看到的就不是几十条长得差不多的SQL而是一条SELECT * FROM orders WHERE id ?的总执行次数和总耗时直观很多。slf4j Filter的作用是打日志。开了这个Filter后Druid会把执行的SQL、执行参数、耗时信息输出到日志系统。注意这里有过量日志刷盘的风险高峰期每秒可能打印几千条SQL需要合理配置日志级别和异步Appender否则日志I/O会成为新的瓶颈。我自己的方式是单独给SQL日志建一个Logger设置独立文件并按天滚动然后定期清理。3. 监控面板和Filter机制Druid能成为首选的关键3.1 StatViewServlet几分钟搭好一个监控页面Druid自带的监控面板是一个非常直观的运维工具。在Spring Boot里接入也很简单配置一个Servlet就可以了。一个基础配置长这样Configuration public class DruidMonitorConfig { Bean public ServletRegistrationBeanStatViewServlet statViewServletRegistrationBean() { ServletRegistrationBeanStatViewServlet registration new ServletRegistrationBean(new StatViewServlet(), /druid/*); registration.addInitParameter(loginUsername, admin); registration.addInitParameter(loginPassword, admin123); registration.addInitParameter(resetEnable, false); return registration; } Bean public FilterRegistrationBeanWebStatFilter webStatFilterRegistrationBean() { FilterRegistrationBeanWebStatFilter filter new FilterRegistrationBean(new WebStatFilter()); filter.addUrlPatterns(/*); filter.addInitParameter(exclusions, *.js,*.css,/druid/*); return filter; } }配置好之后启动应用访问/druid/index.html输入账号密码就能看到监控页面。面板上有几个Tab我最常用的是“数据源”和“SQL监控”。“SQL监控”页面会展示上面提到的合并后的SQL列表每一条都有执行次数、总耗时、最大耗时、返回行数等指标。按总耗时排序基本就能把系统的Top慢SQL拉出来。我前面提到的那个精准定位慢SQL的场景就是在这个页面里完成的。另外两个值得看的指标是activeCount和waitCount。activeCount代表当前被借走的连接数如果长期接近max-active说明连接不够用waitCount表示等待获取连接的次数这个数字快速增长往往意味着连接池已经打满请求在排队。这两个指标能从数据源页面直接看到不需要额外写监控代码。顺带提醒一句生产环境一定要给监控页配账号密码并且不要用弱密码。这个页面暴露的信息非常详细包括SQL文本、连接创建次数、事务耗时等一旦泄露给攻击者相当于把数据库的底牌全亮出来了。3.2 wall FilterSQL防火墙的正确打开方式wallFilter是Druid的另一个硬核能力。它内置了一个完整的SQL语法树解析器能把要执行的SQL解析成语法树然后根据配置的规则做判断符合规则才放行。基础配置一般是spring: datasource: druid: wall: enabled: true multi-statement-allow: false none-base-statement-allow: false condition-and-or-allow: false这几个参数的解释multi-statement-allow控制是否允许一次执行多条SQL。为false时直接拦截类似SELECT 1; DROP TABLE users;这种拼接注入。none-base-statement-allow为false时非标准的SQL语句不在基本语句类型列表里的会被拒绝执行。condition-and-or-allow为false时不允许多个AND/OR条件混用这能挡住不少重逻辑的注入尝试。配置好之后可以主动做个小验证往接口传一个 OR 11这类参数观察日志Druid会输出sql injection相关的拦截警告SQL本身不会真正执行。这里要特别说明一点wall是防注入的辅助手段不是替代SQL预编译。最佳姿势是两层都做代码层统一使用预编译语句占位符传递参数wall作为兜底拦截那些因为历史原因或框架漏洞绕过预编译的SQL。只靠防火墙不写预编译早晚要出事。4. 实操过程中踩过的坑与排查思路4.1 MySQL 8小时断开连接问题keepAlive能救但不万能这是一个经典场景不少老项目都遇到过应用跑了一晚上第二天早上一来业务报一堆Communications link failure或Connection is not available重启应用就好过一阵又复发。背后原因是MySQL服务端有wait_timeout参数默认8小时。如果一条连接连续空闲超过这个时间服务端就会主动把它断掉。但连接池客户端并不知道这条连接已经死了下次从池子里借出这条连接执行SQL时才发现连接早就不可用于是报错。Druid解决的思路分两层。第一层是test-while-idle加validation-query后台线程在巡检空闲连接时自动检测发现失效就踢出池子并新建一条补上。第二层是keep-alive当池子里连接数低于min-idle时keepAlive线程会主动探测并补充连接确保池子里的连接不长期闲置。但有一个坑如果你把min-idle设为0那么即使开了keep-alive空闲时池子里可能一条连接都不剩keepAlive也救不了你。想彻底解决8小时问题min-idle至少要有1到5让池子里始终有活连接在滚动心跳。还要提一个场景容器环境下Druid所在的Pod在做滚动发布时旧Pod的连接是没来得及归还的。如果应用优雅下线逻辑没处理好数据库这边会残留一堆Sleeping状态的连接长期不释放。这种问题在接入K8s后尤其常见需要同时处理连接池的回收和应用生命周期管理光靠连接池参数是不够的。4.2 连接被占满activeCount只增不减——连接泄露排查有一个让运维和开发都很头秃的问题系统运行一段时间后监控面板上的activeCount逐渐上涨到最后稳定在max-active附近数据库慢SQL不多但新请求却拿不到连接报GetConnectionTimeoutException。这个问题的真凶绝大多数是“连接泄露”代码里某个分支在获取连接后没有在finally块里归还或关闭导致连接被无限期占用。查起来很痛苦因为日志里看不出具体是哪个代码段没关闭连接。Druid提供了两个非常有用的配置来辅助排查spring: datasource: druid: remove-abandoned: true remove-abandoned-timeout: 180 log-abandoned: trueremove-abandoned: true开启后连接被借出超过remove-abandoned-timeout秒还没归还Druid会直接强制回收这条连接。log-abandoned: true会在回收时打印当时的调用栈信息这样你就能在日志里看到究竟是哪段代码、哪个方法拿走了连接不还。需要说明的是remove-abandoned是个双刃剑如果系统里有正常的长事务比如批量处理几百条数据开启后可能会被误杀直接中断事务导致数据不一致。所以我一般建议在排查阶段临时开启找到元凶修复后再关掉或者把remove-abandoned-timeout配得比正常最长事务耗时再长一些比如正常事务最长2分钟那就配300秒以上。排查连接泄露还有一招排查时先在监控面板记录activeCount的心跳数据再过半小时查看它是否下降。正常情况没有请求时连接应该归还到min-idle水位。如果activeCount一直挂着不动高度怀疑就是连接泄露。4.3 连接池初始化慢与首次访问卡顿这个问题不算严重但很多第一次用Druid的人会遇到。应用启动后第一次请求特别慢甚至超时但后续就正常了。原因有两方面一是initial-size配置了热身连接启动时创建这些连接本身就有开销二是首次请求时连接池还没完全热身要现场创建连接走一遍完整的建连过程。解决办法很简单应用启动后做一次简单的预热访问比如首页或者一个/health接口或者把initial-size调大。如果是K8s环境为应用配置就绪探针时把就绪判断做得严格一点确保连接池在接收流量前已经完成初始化。4.4 常见问题速查表现象可能原因排查与解决思路报wait millis 60000max-active打满连接被占满查看监控面板activeCount、waitCount判断是并发过高还是连接泄露凌晨/一夜后报连接失效MySQLwait_timeout回收了空闲连接开启keep-alivemin-idle建议设为大于0SQL监控页面空白filters没包含stat检查filters: stat是否配置确认连接池确实是Druid应用启动很慢initial-size过大或库网络较慢调整initial-size在Pod就绪探针中预热连接CPU飙升且连接频繁创建max-active反复在0和峰值间跳动增大min-idle避免连接反复创建销毁日志出现sql injection警告wall拦截了疑似注入SQL查看具体SQL文本确认是攻击还是误杀误杀则调整wall规则5. 关于连接池选型的一些真实体会文章到最后聊聊我这个几年实战下来对连接池选型的真实看法。如果你问的是“性能和功能到底怎么平衡”我个人已经把Druid当作Java后端项目的默认选择了极少因为“性能略微不如HikariCP”这个理由换掉它。因为在我的实际项目里绝大多数系统的瓶颈都不在连接池这十几毫秒的差距上而在线慢SQL、连接泄露、偶发连接不可用这类问题上。Druid的监控能力让这三类问题的定位成本低了一个量级这是性能表上几个百分点完全比不了的。但也有些场景我会选HikariCP比如项目本身极其轻量连监控面板都不需要或者对包体大小要求苛刻的网关类服务又或者公司已有统一的链路追踪体系连接池的监控跟业务监控重合度高。这时候Druid的完整功能反而成了多余的重量。最后再分享一个配置习惯如果你决定用Druid上线前一定要花半小时把手里的连接池参数过一遍至少确认这几项max-active和数据库最大连接数之间留有余量、max-wait不超过网关超时时间、initial-size和min-idle不为0、filters里stat和wall都开了。这五项我几乎每个项目都会复核也是Druid能稳定运行、不被数据库和网关双重殴打的底线配置。