1. 为什么Spring Boot项目要选用Druid连接池
1.1 连接池选型不是小事
做后端开发的朋友大概率都跟数据库连接池打过交道。连接池本质上是一个复用连接的管理器，底层的连接建立和销毁是很重的操作，如果每次数据库操作都新建连接，在高并发下你的服务基本会被拖垮。正因为如此，连接池的性能和功能直接决定了数据库层的稳定性。
Spring Boot 2.x默认使用HikariCP，它性能极好，代码量也少。但性能好不代表功能全。HikariCP的定位是纯粹的连接管理工具，它没有内置的SQL监控、慢查询记录、防火墙、Web界面可视化这些能力。当你的系统需要做数据库性能排查、安全拦截、运行期动态调整连接数时，就不得不另起炉灶。
而Druid在连接池领域是一个很特别的存在。它是一个功能完备的连接池，也是一套数据库监控体系。你可以直接看到每个SQL的执行次数、耗时分布、并发情况，可以查看活跃连接数和空闲连接数，甚至可以拦截带有明显攻击特征的SQL。这些能力在排查线上问题时价值极大。
1.2 监控能力才是真正的杀手锏
如果只是比连接管理的底层性能，Druid和HikariCP的差距并没有想象中那么大。但一旦你的团队需要回答"系统慢的原因在哪里""哪条SQL占用了80%的资源""当前连接数是不是逼近了数据库上限"这些问题时，Druid的价值就完全体现出来了。它自带的StatViewServlet可以提供WEB监控页面，把数据源的实时状态、SQL统计、Session情况、Spring方法调用等全部可视化。
另外一个常被忽视的点是WallFilter，也就是SQL防火墙。它直接拦截常见的SQL注入攻击，比如单引号连续拼接、注释符绕过、函数调用攻击等。对于没有统一SQL审计平台的中小型团队来说，这一层防护能帮你挡掉大部分低级的注入尝试。
1.3 你在什么场景下应该选择Druid
根据我自己的经验，以下三种场景特别适合切换到Druid：第一种是对SQL执行过程有强监控诉求的项目，比如涉及大量慢查询优化、需要结合运维报表分析数据库负载的；第二种是有多数据源、读写分离、分库分表这些复杂度，需要统一管理连接池状态的场景；第三种是安全合规压力比较大的项目，比如面向公网、容易被扫描和攻击的业务系统。
反过来，如果你的项目只是一个内部小工具，连接量一直很平稳，没有监控和拦截的需求，那HikariCP也足够用了。直接引入Druid只会增加管理成本和启动复杂度。选型这件事情，永远是为自己的实际需求服务的。
2. 依赖引入与版本对应关系
2.1 引入druid-spring-boot-starter的正确姿势
要让Druid在Spring Boot里跑起来，最省事的做法是引入官方提供的starter。它的好处是自动装配了数据源配置、监控Filter、Servlet等基础设施，你只需要在配置文件里写参数即可。
在Maven项目中，pom.xml里添加如下依赖：
<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.20</version> </dependency>注意，这个版本是与Spring Boot 2.x配套的。如果你的项目已经是Spring Boot 3.x，那么需要引入另一个独立的坐标：
<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-3-starter</artifactId> <version>1.2.20</version> </dependency>这个3.x版本专门适配了Jakarta命名空间迁移，直接使用旧版starter在Spring Boot 3.x下启动会报ClassNotFoundException。这是我最初切换Spring Boot 3时踩到的坑，当时盯着报错信息看了很久，最后才意识到是命名空间变更导致的。
2.2 版本兼容性排查：最常见的启动报错
starter引入之后，最常见的启动报错有两类。第一类是找不到数据库驱动类，也就是Cannot load driver class: com.mysql.cj.jdbc.Driver。这通常是因为你引入了Druid，但忘记同时引入对应的数据库驱动依赖。以MySQL为例，需要确保pom里有这个：
<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>第二类报错是Failed to configure a DataSource。这个报错的本质是Spring Boot自动装配在启动时没有找到可用的数据源配置。你需要检查application.yml中是否配置了spring.datasource.url、username、password这些基本属性。有些人会把配置写在druid.datasource前缀下面，这里要特别注意，Druid在Spring Boot下的默认配置前缀是spring.datasource.druid，不是单纯的druid。如果前缀写错，配置自动扫描不到，启动就会失败。
我在最初使用这个starter时，就是因为参考了一份老旧示例，把所有配置写在了druid:节点下，结果花了不少时间才定位到问题。现在写配置我统一用spring.datasource.druid前缀，清晰且稳定。
3. 连接池参数配置逐项拆解
3.1 基础连接参数：initialSize、minIdle与maxActive
Druid的参数体系非常丰富，但真正需要一开始就关心的就那么几个。下面是一份我常用的基础配置示例：
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 pool-prepared-statements: true max-open-prepared-statements: 20 max-pool-prepared-statement-per-connection-size: 20先说initial-size，它代表连接池启动时初始创建的连接个数。为什么要设初值？因为在系统启动后的第一波请求到来时，如果连接池是空的，所有请求都要排队等连接创建，瞬间延迟会很高。设置成5可以提前建立连接，避免冷启动抖动。
min-idle是连接池中允许保持的最小空闲连接数。当系统长时间没有请求时，Druid会通过后台线程把空闲连接维持在min-idle的水平。而max-active是最大活跃连接数，它表示连接池最多能同时向外发放的连接数量。如果业务并发很高，这个数字不够，请求就会在连接池端等待，甚至超时。
max-wait是获取连接的最大等待时间，单位毫秒。超出这个时间还没有拿到连接，就会抛出异常。这里我比较谨慎，一般控制在60秒以内。如果你的系统经常出现获取连接超时的报错，先不要盲目调大max-wait，要优先检查是否有连接泄漏，否则只是延长了故障的感知时间。
3.2 连接有效性检测与空闲回收机制
数据库连接不是永久的，网络闪断、数据库重启、防火墙会话超时都会导致连接变成不可用状态。你想要在拿到连接之前就确认它是否有效，就离不开连接检测机制。
validation-query是探测SQL，MySQL用SELECT 1，Oracle可能用SELECT 1 FROM DUAL，PostgreSQL同样用SELECT 1。test-while-idle表示空闲连接是否定期检测有效性。当连接空闲时间超过time-between-eviction-runs-millis的间隔后，Druid会执行一次探测，无效连接会被清除。而test-on-borrow和test-on-return分别表示取用和归还连接时是否实时检测。
从性能角度讲，test-on-borrow: true会让每次取连接都额外执行一次探测SQL，虽然最保险，但也带来了不必要的开销。我通常在test-while-idle开启的前提下，保持test-on-borrow关闭。如果数据库经常出现连接异常，才临时打开它排查。
min-evictable-idle-time-millis控制的是空闲连接的最小存活时间，默认是30分钟。意思是一个连接空闲超过这个时间，在下次回收扫描中就可能被销毁。如果你的连接池经常出现"刚刚创建的连接很快又释放"的情况，可以把空闲淘汰时间调长一点，避免频繁重建连接。
3.3 慢SQL监控与耗时阈值配置
既然引入了Druid，不利用它的SQL监控就太亏了。慢SQL是数据库性能隐患的最大来源。Druid的Filter可以统计每个SQL的执行次数、总耗时和并发数。默认情况下，在application.yml中开启以下配置：
spring: datasource: druid: filter: stat: enabled: true log-slow-sql: true slow-sql-millis: 3000slow-sql-millis用来定义什么样的SQL算慢，我这里设成3000毫秒。一旦有SQL超过这个阈值，Druid就会输出日志。你也可以设置为1000毫秒，更敏感地捕捉性能劣化。但要注意，阈值设置太小会产生大量日志，反而干扰排查。我一般结合业务容忍度：在线交易系统调到1000，管理后台调到3000。
同时建议开启合并统计：
spring: datasource: druid: web-stat-filter: enabled: true url-pattern: /* stat-view-servlet: enabled: true url-pattern: /druid/*web-stat-filter会拦截Web请求，统计每个请求对应的SQL执行情况。配合stat-view-servlet可以在浏览器中访问/druid/index.html，看到实时SQL的监控面板，包括每个接口调用了哪些SQL，执行了多少次，平均耗时是多少。这层能力在压测和问题复现阶段非常实用。
4. 监控页面的启用与访问
4.1 通过配置类显式注册StatViewServlet
如果单纯用starter的自动配置，有时候监控页并不会按预期生效。问题通常在于stat-view-servlet没有对应的Servlet注册。我建议在Spring Boot配置类中显式注册StatViewServlet，这样可控性更强。示例代码如下：
import com.alibaba.druid.support.http.StatViewServlet; import org.springframework.boot.web.servlet.ServletRegistrationBean; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class DruidMonitorConfig { @Bean public ServletRegistrationBean<StatViewServlet> druidStatViewServlet() { ServletRegistrationBean<StatViewServlet> registration = new ServletRegistrationBean<>(new StatViewServlet()); registration.addUrlMappings("/druid/*"); registration.addInitParameter("allow", "127.0.0.1"); registration.addInitParameter("deny", ""); registration.addInitParameter("loginUsername", "druid"); registration.addInitParameter("loginPassword", "druid123"); registration.addInitParameter("resetEnable", "false"); return registration; } }allow表示允许访问的IP，这里我写了127.0.0.1，也就是只有本机可以访问。如果你在服务器上部署了，需要把运维出口的公网IP加进去，或者直接通过内网访问。deny是禁止访问的IP，留空表示不限制。loginUsername和loginPassword是访问监控页时需要输入的账号密码。这个密码不能设置得太简单，Druid监控页暴露SQL统计和连接池信息，一旦泄露是严重的安全隐患。
还有一个resetEnable参数，设置为false表示禁止在监控页面重置数据。如果你允许重置，别人可以一键清空你的SQL统计，排查问题的时候就会失去历史数据，所以我一般都是关闭的。
4.2 监控页的核心指标怎么看
启动项目后，访问http://localhost:8080/druid/index.html，输入账号密码，就会进入Druid的监控首页。第一次打开可能有点不知所措，因为面板上的指标太多了。这里我根据实际排查问题的经验，给你一个阅读优先级：
第一个是数据源页签。你会看到当前连接池的配置参数、活跃连接数、空闲连接数、逻辑建立连接数、逻辑关闭连接数。如果活跃连接数长期贴近max-active，说明连接池压力大；如果空闲连接一直为0，说明连接周转太快，要考虑调大max-active。
第二个是SQL监控页签。这里列出了所有执行过的SQL，按执行次数和耗时排名。重点看两个指标：执行时间和返回行数。如果某条SQL的执行时间明显高于其他SQL，结合执行计划优化对应SQL即可。如果某条SQL被调用了上万次，但每次都是小查询，那就要在业务层面考虑缓存。
第三个是URI监控页签。它会显示每个HTTP接口的请求次数、请求时间、关联SQL数。这个指标的价值在于，你能把"接口慢"和"SQL慢"直接关联起来，定位效率非常高。
4.3 SQL防火墙WallFilter的实战配置
WallFilter是Druid的亮点之一，它本质上是一个带规则引擎的SQL解析器，会分析SQL的语法结构，命中风险规则就直接拦截。配置方式如下：
spring: datasource: druid: filter: wall: enabled: true config: multi-statement-allow: false none-base-statement-allow: false comment-allow: false delete-allow: true update-allow: truemulti-statement-allow表示是否允许多条SQL语句一次执行，默认false。不允许时，类似SELECT * FROM user; DELETE FROM user;这种组合语句会被拦截，这能有效防止SQL注入中的堆叠查询。comment-allow设为false后，SQL中带有注释的写法会直接拦截，因为注释经常被用来绕过过滤规则。delete-allow和update-allow控制是否允许删除和更新操作，如果业务上不允许某些表直接删除，可以在这里做表级别配置。
WallFilter是细粒度的，它的拦截日志会打印未通过校验的SQL语句。在生产环境开启时，建议先观察一段时间的拦截日志，看看有没有误杀正常业务SQL。比如业务代码中用了特殊的函数，或者ORM框架自动生成的SQL包含你预期外的结构，都可能导致拦截。通常我会先用测试环境压一遍主流程接口，确认没有拦截问题再上生产。
5. 多数据源场景下的配置进阶
5.1 动态数据源方案与Druid结合
一个项目里面同时连接多个数据库的需求很常见。比如主从分离、多业务库共存。Spring Boot集成Druid之后，多数据源的配置需要手动创建数据源Bean，不能只依赖自动配置。下面是一个简化的示例：
@Configuration public class MultiDataSourceConfig { @Bean(name = "primaryDataSource") @ConfigurationProperties(prefix = "spring.datasource.druid.primary") public DataSource primaryDataSource() { return DruidDataSourceBuilder.create().build(); } @Bean(name = "secondaryDataSource") @ConfigurationProperties(prefix = "spring.datasource.druid.secondary") public DataSource secondaryDataSource() { return DruidDataSourceBuilder.create().build(); } }对应的配置文件需要把不同数据源的参数分开：
spring: datasource: druid: primary: url: jdbc:mysql://localhost:3306/db_main username: root password: root123 initial-size: 5 max-active: 20 secondary: url: jdbc:mysql://localhost:3306/db_report username: report password: report123 initial-size: 3 max-active: 10当多个数据源都注册成Spring容器中的DataSource时，你需要给其中一个标注@Primary，否则Spring的自动注入会因为找不到唯一候选而报错。同时建议给所有数据源设置明显的名称，方便在监控页区分。
5.2 多个数据源的监控隔离
多数据源带来的一个问题是监控数据混在一起。好在Druid的监控数据是按数据源名称分开记录的。在StatViewServlet的监控页面上，你可以看到每个数据源各自的连接数和SQL统计。
如果你启用的是动态数据源，有现成的动态数据源框架可以跟Druid配合。以前我在一个模拟项目X中用了动态数据源，把读写流量分发到不同库，同时保留了Druid监控，排查某个耗时接口时，先到URI监控看到接口耗时高，再到SQL监控看到对应库的慢SQL，整个过程一气呵成。多个数据源的时候，监控隔离要比统一汇总更有意义，因为不同库的负载模型可能完全不同。
6. 踩坑实录：从启动报错到连接泄漏
6.1 坑一：starter版本与Spring Boot版本不匹配
Spring Boot 3.x发布后，很多人把项目从2.x升级到3.x，但Druid的starter没有同步更新，于是启动报错java.lang.ClassNotFoundException: javax.servlet.Servlet。我当时第一反应是缺少Servlet依赖，排查了半天才意识到Spring Boot 3已经改成Jakarta命名空间。解决方法是使用druid-spring-boot-3-starter。
这个问题对那些依赖大量老组件的存量项目影响特别大。如果你在升级Spring Boot版本之前没有预先检查三方starter的适配情况，很可能被各种ClassNotFoundException拖慢进度。建议在升级前用IDE扫描依赖树，检查所有javax.*相关的三方库是否提供了包含jakarta.*的新版本。
6.2 坑二：开启WallFilter后SQL被拦截
有一次我把WallFilter在测试环境全部打开，结果一些原本运行正常的接口开始返回"数据源被禁止"之类的信息。检查拦截日志后发现，是ORM框架在生成SQL时使用了多值插入的语法，触发了多语句拦截规则。这种情况下，你可以把multi-statement-allow设为true，但这是有风险的，等于放开了多语句执行。
更合理的方案是调整代码，把大批量插入拆成单条插入，或者在WallFilter的黑名单里精确排除某个表名。不要为了跑通业务就一刀切关掉防火墙，安全能力一旦关闭，再想开回来可能就要等到下一次攻击事件了。
6.3 坑三：连接泄漏的排查思路
连接泄漏是连接池最头疼的问题之一。表现是数据库连接数不断上涨，应用报获取连接超时，重启后短暂恢复正常，过一段时间又退化。Druid监控页的"数据源"页签中，如果逻辑连接打开数与逻辑连接关闭数长期不一致，就说明有连接没有归还。
我排查连接泄漏的步骤一般是这样：先看监控页找出泄漏的数据源，再通过active stack trace功能查看当前活跃连接的线程栈，能直接定位到是哪个业务代码持有了连接没有释放。其次检查代码中是否有异常路径把finally块省略了，导致连接没有关闭。最后确认事务注解是否打在了非public方法上，这种情况下Spring事务拦截不生效，连接也不会被事务管理器自动归还。
这里记住一个原则：DataSourceUtils.releaseConnection或在finally中调用close，是连接使用的兜底逻辑。使用Spring的JdbcTemplate或MyBatis时，这些框架会自动归还连接，不需要手动关闭；但如果你直接使用了Connection对象，一定要在finally块中关闭。
7. 池大小设置的黄金法则与运行期调优
7.1 连接数不是越多越好
很多初学者会觉得max-active配得越大，性能越好，其实不是这样。数据库的并发处理能力是有上限的，超过上限后，增加连接数反而会因为上下文切换和锁竞争导致吞吐量下降。PostgreSQL和MySQL在连接数过大的情况下，CPU消耗会显著上升。
我通常的估算方法是：max-active = 应用实例数 × 核心并发线程数 × (单请求访问数据库的次数 + 1)。举例来说，假设你有3个应用实例，每个实例高峰期并发线程200个，平均一个请求访问数据库2次，那么总连接峰值约为3×200×2=1200，再除以数据库健康系数0.6，大概等于2000。但这个数字往往偏大，实际还要根据压测结果回调。更通用的做法是先设置一个保守值，比如max-active=100，连续压测观察监控页的活跃连接数曲线，如果曲线非常平缓且存在大量空闲连接，就逐步下调；如果曲线触顶，才适当上调。
7.2 生产环境的监控告警配置
Druid本身提供监控能力，但它不提供告警能力。你需要把关键指标接入自己的监控体系。我个人的做法是启动一个定时任务，每秒读取DruidDataSource的getActiveCount()和getPoolingCount()，一旦活跃连接数连续3次超过max-active的80%，就发一条告警到工作群。
另外，建议把慢SQL日志单独输出到独立文件。在logback.xml中为慢SQL配置一个单独的Logger，这样即使整体日志被滚动清理，慢SQL历史数据也可以保留较长时间，为后续索引优化提供依据。我见过很多团队在应用变慢时才想起看慢SQL，但慢SQL日志已经被日常日志淹没，或者被清理掉了，非常可惜。
7.3 最后的实用技巧
最后分享一个小技巧：在不同环境的配置文件中，Druid的监控页账号密码和连接池参数通常应该不同。排查问题时，不要只看生产环境的监控，强烈建议在本地开发环境也开启Druid监控。本地调试时，它能非常直观地反映出你写的接口每次请求执行了几条SQL、每条SQL耗时多少、有没有重复查询。很多人觉得本地没有监控需求，恰恰是本地这种低并发环境，能更快暴露出SQL冗杂和循环查询的问题。
另外一个容易忽略的点是预热。应用上线后如果瞬间涌入大量请求，连接池的初始大小不足以撑住流量，会导致前几十秒的接口超时。解决方案是在应用启动完成后，通过健康检查接口触发一次预热请求，或者把initial-size适当调大。这个优化我在模拟项目X中实测过，预热前后首请求的耗时差距非常明显。
