企业官网建设流程全解析

Spring Boot 3系列学到这里，数据库这块肯定绕不开连接池。前面几篇我们用默认的HikariCP跑得好好的，但一旦项目上了监控、要做慢SQL分析、要防SQL注入，HikariCP就有点不够用了。这篇我把自己在Spring Boot 3里接入Druid的完整过程整理出来，从依赖引入、参数配置、监控页面开启到各种坑，一次性说清楚，方便后面自己查，也给正在折腾的朋友一个参考。

Druid是阿里开源的一个数据库连接池组件，不光是连接池，它还自带监控、SQL防火墙、日志记录这些能力。在Spring Boot 3之前，接入Druid其实挺简单，一个druid-spring-boot-starter就完事了。但Spring Boot 3出来之后情况变了，javax换成了jakarta，很多老配置方式直接失效，网上教程又大多是旧的，照着抄多半会翻车。这篇就是基于Spring Boot 3.2.x + Druid 1.2.20+的实测配置，确保能跑通。

1. 为什么还是Druid：连接池选型这码事

1.1 连接池之间的那些差异

很多新手会问，Spring Boot 2.x开始默认就是HikariCP了，性能测试里HikariCP经常排第一，为什么还要换Druid？这个问题的答案不在“连接池性能”本身，而在“除了连接池之外你还需要什么”。

HikariCP的定位非常纯粹，就是快，极致的快。它的字节码做了极致优化，方法调用链路短，性能损耗极小。但纯粹也意味着功能少，它没有内置的监控面板、没有SQL分析、没有防SQL注入能力。你要想看慢SQL，得自己去接Micrometer、Prometheus那套；要想拦SQL注入，得在应用层自己写过滤器。

Druid走的是另一条路线：连接池只是它的基础能力，真正的核心价值在于监控和防护。它能统计每个SQL的执行时间、执行次数、返回行数、并发线程数，能检测慢SQL并打印日志，还能通过WallFilter做SQL防火墙，拦截常见的注入攻击。对于国内企业项目来说，这些能力很多时候是刚需，尤其是要过等保或者内部有数据库审计要求的场景。

还有一点很实际：Druid的监控数据是中文界面，操作简单，给团队里的非Java人员看也毫无压力。HikariCP配Prometheus那套，光教他们看Grafana面板就得花不少时间。

1.2 在Spring Boot 3里用Druid的几个理由

我选Druid，具体来说有三个实实在在的理由。

第一，慢SQL监控。生产环境数据库出问题，十有八九是慢查询引起的。Druid的监控页能直接看到哪些SQL执行时间长、执行了多少次，甚至可以设置阈值，超过就告警。这个能力在做性能优化和排查线上问题时太重要了。

第二，SQL防火墙。Druid的WallFilter能拦截很多常见的SQL注入Payload，比如' OR '1'='1这类，在应用层面就拦掉了，不用全指望数据库的权限控制。虽然MyBatis的#{}预编译已经防住了大部分注入，但总有写动态SQL、用${}拼接的时候，多一层防护总是好的。

第三，连接泄漏检测。Druid可以设置removeAbandoned，自动回收那些长时间未关闭的数据库连接。这个功能在排查连接泄漏时简直救命。我见过一个老项目，代码里有几个地方忘了关连接，平时跑着没事，一到高峰期连接池就被打满，接口全部超时。加上Druid的泄漏检测后，直接定位到了具体代码，修掉就好了。

换个角度说，如果你只是个简单的CRUD项目，内部系统，并发不大，也没有监控需求，那HikariCP完全够用，没必要换。技术选型这事，够用就好，不要为了用而用。

2. 环境准备与依赖引入

2.1 准备工作清单

按下面的版本组合来，我实测没问题：

• JDK：17或21（Spring Boot 3要求最低17）
• Spring Boot：3.2.x（我用的是3.2.5）
• Maven：3.8+
• Druid：1.2.20及以上
• MySQL：8.x（其他数据库也支持，配置略有不同）

如果你是Gradle项目，思路一样，把Maven依赖换成Gradle语法就行。另外，Spring Boot 3.2.x需要JDK17，别用JDK8，编译都过不去。

2.2 引入druid-spring-boot-3-starter

这是第一篇重头戏。Spring Boot 3的包名从javax.*迁移到了jakarta.*，所以Druid官方专门出了一套适配Spring Boot 3的starter，注意坐标：

<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-3-starter</artifactId> <version>1.2.20</version> </dependency>

看清楚，是druid-spring-boot-3-starter，不是老的druid-spring-boot-starter。如果你按照Spring Boot 2.x的教程引入了老坐标，运行时会报一堆奇怪的错，比如ClassNotFoundException: javax.sql.DataSource或者自动配置不生效。

注意：Druid 1.2.20以上版本对Spring Boot 3.x适配才比较稳定，低于这个版本建议升级。我一开始用了1.2.18，监控页面的统计数据偶尔会丢失，升级到1.2.20后问题消失。

另外还会带上MySQL驱动和JDBC依赖：

<dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency>

如果你用MyBatis，再把MyBatis的starter也加上。顺序无所谓，Maven会自己处理依赖关系，但版本号最好固定下来，方便团队统一。

3. 最小配置：先让Druid跑起来

3.1 配置数据源核心参数

依赖加好之后，在application.yml里配置数据源。这是最基础的版本，先跑通，再逐步添加监控、防火墙那些特性：

spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/your_database?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: your_password druid: # 初始连接数 initial-size: 5 # 最小空闲连接数 min-idle: 5 # 最大连接数 max-active: 20 # 获取连接的最大等待时间（毫秒） max-wait: 60000

有个关键点：Spring Boot 3 + druid-spring-boot-3-starter 会自动读取spring.datasource.druid.*下的配置，所以url、username这些可以直接放在spring.datasource下，也可以放在spring.datasource.druid下。但建议把Druid特有的参数统一放druid节点下，跟基础数据源配置分开，逻辑清晰一些。

type这个参数其实可以省略，因为引入了Druid starter之后，它会自动把DruidDataSource注册为默认的数据源实现。但建议显式写上，防止团队里有人不清楚用的哪个连接池。

配置完之后，启动项目，看到日志里有[DruidConnectionPool]相关的初始化信息，就说明Druid已经接上了。

3.2 验证连接池是否真的生效

很多朋友配置完了，项目也启动成功了，就以为Druid生效了。实际上Spring Boot的自动配置有时会静默失败，你以为用的是Druid，实际用的还是HikariCP。怎么验证？两种方法。

第一种，启动日志大法。Spring Boot启动时会打印数据源的类型，留意这行：

2024-06-15T10:23:45.123+08:00 INFO 12345 --- [main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Starting...

如果看到HikariDataSource，说明Druid根本没生效，检查一下依赖坐标对不对，有没有引入冲突。

第二种，写个测试接口或者用ApplicationRunner在启动时打印数据源类型：

@Component public class DataSourcePrinter implements ApplicationRunner { private final DataSource dataSource; public DataSourcePrinter(DataSource dataSource) { this.dataSource = dataSource; } @Override public void run(ApplicationArguments args) { System.out.println("当前数据源类型: " + dataSource.getClass().getName()); } }

如果打印出来是com.alibaba.druid.pool.DruidDataSource，那就稳了。这个方法排查问题特别有用，推荐留着。

另外，Druid连接池启动后，默认会有一些后台线程，比如Druid-ConnectionPool-Create-*，你可以通过jstack看到这些线程。在bin目录执行：

jstack <pid> | grep Druid

能看到一堆连接创建、回收相关的线程，说明连接池确实在正常工作。

4. 监控页面与安全注意

4.1 开启StatViewServlet

Druid最有价值的功能之一就是监控页面，通过一个Servlet暴露HTTP接口，浏览器访问就能看到连接池状态、SQL统计、慢SQL记录、Session监控等。在Spring Boot 3里配置方法如下：

spring: datasource: druid: stat-view-servlet: # 开启监控页面 enabled: true # 访问路径 url-pattern: /druid/* # 监控页面登录用户名 login-username: admin # 监控页面登录密码 login-password: admin123 # 允许清空统计数据的IP reset-enable: false

配置好之后，启动项目，浏览器访问http://localhost:8080/druid/index.html，会弹出一个登录框，输入你设置的用户名密码，就能看到监控面板了。

监控页面包含几块内容，我简单说明一下：

• 数据源：显示当前连接池的活跃连接数、空闲连接数、等待次数、创建连接数等，一眼看出连接池的健康状态。
• SQL监控：列出所有执行过的SQL，按执行次数、总耗时、最大耗时、错误次数排序。点进去可以看到每条SQL的完整语句和参数。
• 慢SQL：自动记录超过slowSqlMillis阈值的SQL，默认是3000毫秒。
• Session监控：显示当前活跃的Session、请求的URL、执行时间等。
• URI监控：统计每个接口的调用次数、耗时、并发情况。

4.2 弱口令风险提醒

这里要特别说一个非常严肃的问题：监控页面一定要改默认账号密码。

网上一搜Druid监控页面，很多教程都用admin/admin或者admin/123456，生产环境如果这么配，等于把数据库状态裸奔在公网上。攻击者只要能访问到/druid/index.html，用弱口令登录进去，就能看到你的SQL语句、表结构、甚至连接信息，再结合SQL注入或者弱口令直接连数据库，后果不堪设想。

我见过一个真实案例，某个公司的测试环境把Druid监控暴露在公网，密码是admin/admin，被扫描器扫到后，攻击者登录进去看了SQL监控，发现一个后台管理接口存在SQL注入，直接拖走了整个用户表数据。后来排查，发现扫描器就是通过Druid监控页的指纹识别出的系统类型。

所以，配置监控页面要记住几条原则：

1. 密码一定要复杂，至少12位，包含大小写字母、数字、特殊字符。
2. 不要用admin作为用户名，改成其他不常见的名称。
3. 生产环境不要暴露到公网，通过内网访问即可，或者用Nginx加IP白名单。
4. 不需要远程访问时，直接enabled: false关掉监控页面，需要时再开。

spring: datasource: druid: stat-view-servlet: enabled: true url-pattern: /druid/* # 用户名不要用admin login-username: monitor_ops # 密码务必复杂 login-password: "Xk#9vP@2mQ$8" # 重置按钮关掉 reset-enable: false # 只允许内网IP访问（根据你的网段调整） allow: 127.0.0.1,192.168.1.0/24 # 拒绝所有其他IP deny:

allow和deny参数支持IP或网段，多个用逗号分隔。配置了allow之后，只有匹配的IP才能访问监控页面，其他IP直接403。这一层防护非常有效，建议一定要加。

4.3 防火墙和SQL过滤配置

Druid的另一个安全组件是WallFilter，即SQL防火墙。它可以在SQL执行前进行语法校验和注入检测，拦截掉有风险的SQL。配置如下：

spring: datasource: druid: filter: wall: enabled: true config: # 是否允许多条SQL同时执行 multi-statement-allow: false # 是否允许非基本语句（如DROP、TRUNCATE） none-base-statement-allow: false # 是否允许调用存储过程 call-allow: false # 是否允许SELECT ... INTO OUTFILE select-into-outfile-allow: false # 是否允许DELETE无WHERE条件 delete-where-none-check: false

这些配置的作用：

• multi-statement-allow: false，防止SQL注入时通过分号拼接多条语句。
• none-base-statement-allow: false，禁止执行DDL类高危操作，防止脱库。
• delete-where-none-check: false，禁止不带WHERE条件的DELETE语句，防止误删全表。

不过要提醒一点：WallFilter拦截规则比较严格，有些正常的分页SQL、批量更新SQL可能被误拦。比如MyBatis的<foreach>批量插入，如果生成的SQL包含多条INSERT语句，就会被multi-statement-allow: false拦截。碰到这种情况，需要根据业务实际情况调整WallFilter的规则。

我遇到过最典型的一次：一个批量更新功能，MyBatis生成了一条超长的UPDATE语句，带多个子查询，WallFilter直接拦了，报错信息是SQL被禁止执行。排查半天，最后把none-base-statement-allow放开或者针对该接口单独放行才解决。所以，遇到SQL被莫名其妙拦截的，先检查WallFilter日志，看是哪条规则触发的。

5. 参数详解：从应用到数据库的通道到底怎么调

5.1 核心连接池参数详解

Druid的参数很多，刚接触容易一头雾水。我挑几个最核心的，说明它们的作用和配置建议。

max-active设置多少合适？我见过很多人拍脑袋填个100，觉得越大越好。其实连接池大小跟数据库性能、业务并发量都有关系。连接数太多，数据库CPU和内存扛不住；连接数太少，高并发时线程都在等连接，接口响应变慢。

一个粗略的经验公式：连接数 = ((核心线程数 * 2) + 有效磁盘数)，当然这只是参考，具体要压测。我一般先设20，压测看性能，再调大或调小。

test-on-borrow: false这个很多人不理解，觉得获取连接时检测一下才安全。但每次获取连接都执行一次SELECT 1，在高并发下会白白增加数据库压力。Druid有后台线程定期检测空闲连接（test-while-idle），已经能保证连接池里的连接基本是健康的，test-on-borrow开着反而浪费性能。

5.2 慢SQL与监控参数配置

监控功能除了页面查看，还可以配置慢SQL日志，在日志里输出执行时间超过阈值的SQL：

spring: datasource: druid: # 慢SQL阈值（毫秒），超过则记录到日志 slow-sql-millis: 2000 # 是否打印慢SQL日志 connection-properties: druid.stat.slowSqlMillis=2000 filter: stat: enabled: true # 慢SQL日志开关 log-slow-sql: true # 合并相同SQL（将参数替换为?） merge-sql: true

merge-sql: true建议打开，它会把只有参数不同的SQL合并统计，比如SELECT * FROM user WHERE id = 1和SELECT * FROM user WHERE id = 2会合并成一条，显示执行次数，这样统计页面不会爆掉。

慢SQL阈值设置多少合适？根据业务敏感度来，我一般设2000毫秒，超过2秒的SQL就有优化空间了。如果是高并发系统，可以更激进一点，设置1000。

这里有一个技巧：慢SQL日志输出后，不要只看SQL语句本身，还要结合监控页面的“返回行数”和“执行次数”一起分析。有时候SQL本身不慢，但执行了上千次，累积时间就很可观。这种属于典型的“N+1查询”问题，优化方向是减少SQL执行次数，而不是优化单条SQL。

5.3 坑：Druid什么情况会关闭statement

这个点特别值得单独拿出来说，因为踩坑的人太多了。你在热搜词里也能看到“druid什么情况会关闭statement”这个问题。

Druid的close()方法设计得比较特殊，当你调用Connection.close()时，Druid并不是真正关闭物理连接，而是把连接还回连接池。同时，它会尝试关闭这个连接上所有未关闭的Statement。这就是很多人遇到的问题：明明从连接池拿连接，执行完SQL后关闭了连接，但后面再用同一个Statement就报错“Statement is closed”。

举个例子：

Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE id = ?"); // 执行第一次查询 ps.setInt(1, 1); ResultSet rs = ps.executeQuery(); // ...处理结果 rs.close(); // 此时关闭连接 conn.close(); // 想复用同一个ps再查一次？报错！ ps.setInt(1, 2); ResultSet rs2 = ps.executeQuery(); // SQLException: Statement is closed

原因就是conn.close()触发Druid回收连接时，把statement也一并关了。这其实是Druid的一种自我保护机制，防止连接泄漏，但如果你没有意识到这个设计，就会踩坑。

解决办法很简单：

1. 每次操作都从连接池重新获取连接，不要复用旧的Connection和Statement。
2. 在同一个数据库事务中，保持连接不关闭，事务结束后再关闭。
3. 如果确实要复用Statement，需要在conn.close()之前取出Statement再操作，但这种写法不推荐，复杂且容易出错。

另外有一种情况，Druid会因为removeAbandoned自动回收连接而关闭Statement。当一个连接超过remove-abandoned-timeout没有被关闭，Druid后台线程会强制回收这个连接，并关闭它上面所有Statement。这时候如果代码还在用这个连接执行SQL，就会突然报错。

排查这种问题，看日志里有没有abandoned connection类似的字样，有的话说明触发了泄漏回收。解决方向是检查代码里有没有忘了关闭连接的地方，而不是调大remove-abandoned-timeout——那样只是把问题往后拖。

6. 常见问题与排查技巧

6.1 监控页面没有数据

配置了监控页面，但打开后SQL监控是空的，一条记录都没有。这种情况很常见，原因通常是少了统计过滤器。

Druid的SQL统计依赖StatFilter，需要手动开启：

spring: datasource: druid: filter: stat: enabled: true

没有这个，监控页面的SQL监控、慢SQL统计都是空的。同理，如果想看Web应用的URI监控、Session监控，需要引入spring-boot-starter-web并开启WebStatFilter：

spring: datasource: druid: web-stat-filter: enabled: true # 需要统计的URL路径 url-pattern: /* # 排除静态资源和监控页面本身 exclusions: /druid/*,*.js,*.css,*.gif,*.jpg,*.png

配置完重启，再去操作几个接口，回到监控页面刷新，就能看到数据了。

6.2 配置了但没生效

有时候application.yml里配了一堆Druid参数，但运行时发现根本没生效。排查步骤如下：

第一步，确认引用的starter坐标正确。我遇到过同事引的是老版druid-spring-boot-starter，Spring Boot 3项目根本不会加载它的自动配置，所有参数静默失效。

第二步，检查@SpringBootApplication扫描范围。如果你的启动类不在根包下，而Druid的配置类又没被扫描到，也会出现配置不生效的情况。这个问题比较隐蔽，排查时要留意。

第三步，看日志。Druid启动时会打印自己的配置信息，包括连接池参数，像这样：

[main] INFO com.alibaba.druid.pool.DruidDataSource - {dataSource-1} inited

如果日志里没有DruidConnctionPool相关的信息，基本可以确定Druid没被加载。

6.3 连接池报错排查

最常见的连接池报错是GetConnectionTimeoutException，即获取连接超时。出现这个错误，先看监控页面的“活跃连接数”是不是一直很高。如果是，说明有连接泄漏，代码里有没有关闭ResultSet、Statement、Connection，用remove-abandoned自动回收并打日志定位。

另一种情况是连接池被打满但活跃连接不多，空闲连接也很多，这时候可能是max-wait设置太短，或者连接池创建连接的速度跟不上需求。可以适当调大max-active和max-wait，同时关注数据库本身的连接数限制。

还有一种是SQLException: Data source rejected establishment of connection，这通常是数据库连接数满了。MySQL默认连接数是151，如果应用连接池配置的max-active是100，多个应用实例连同一个数据库，很容易把数据库连接数耗尽。解决办法是调大MySQL的max_connections，或者减小各应用连接池的max-active。

6.4 关于Statement关闭的实战建议汇总

把上面5.3节的内容补充完整，针对Statement关闭问题，我整理了三条实战建议，基本能避免99%的坑：

1. 永远不要在Connection.close()之后去操作Statement。Druid的池化设计决定了close不一定真的关闭，你永远不知道它什么时候会把Statement一起关掉，最安全的做法是每次操作都重新获取连接和预编译语句。

2. 数据库操作要按顺序关闭资源：ResultSet->Statement->Connection。顺序反了也可能导致Statement被提前关闭，特别是在Druid这种池化环境下。

3. 使用Spring的JdbcTemplate、MyBatis这类框架，让框架来管理连接和Statement的声明周期，比手动写JDBC代码安全得多。

如果项目中确实需要手动管理JDBC，建议用try-with-resources语法：

try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ResultSet rs = ps.executeQuery()) { while (rs.next()) { // 处理结果 } }

这样会自动按正确顺序关闭资源，也不会出现连接泄漏。

7. 与MyBatis集成时的额外注意

7.1 插件顺序与配置

如果你的项目用了MyBatis，Druid还可以配合MyBatis的插件机制做更多事情。但要注意，MyBatis的mybatis-spring-boot-starter和Druid的自动配置之间有先后顺序，如果配置不当，MyBatis可能拿到的是HikariCP而不是Druid。

一个稳妥的做法是在application.yml里显式指定：

mybatis: configuration: map-underscore-to-camel-case: true # 指定Mapper XML文件位置 mapper-locations: classpath:mapper/*.xml

MyBatis本身不关心你用什么连接池，它只是从DataSource拿连接。所以只要DataSource注入的是Druid，MyBatis底层自然用的就是Druid。不需要额外配置。

7.2 批量操作的WallFilter误拦

前面说过，WallFilter可能会误拦批量操作的SQL。这里再补充一个具体场景：MyBatis的<foreach>批量INSERT，生成的SQL是：

INSERT INTO user (name, age) VALUES (?, ?), (?, ?), (?, ?)

这种单条多VALUES的批量插入WallFilter默认是放行的，没问题。但如果你是循环调用单条INSERT，生成多条SQL语句，每条末尾带分号，就会触发multi-statement-allow: false拦截。

解决办法有两个：一是把代码里循环插入改成批量插入（推荐，性能也会提升）；二是配置WallFilter放行多条语句，但要注意这样会降低安全性。

7.3 分页插件与Druid的兼容性

MyBatis常用的分页插件PageHelper，跟Druid一起用没什么冲突，但要注意分页插件会在SQL后面拼接LIMIT ?，这属于正常SQL，WallFilter不会拦截。如果你用了自定义拦截器或者改了分页SQL，小心被WallFilter误判。

遇到拦截时，先看Druid的日志文件，它会把被拦截的SQL和拦截原因都打出来。根据拦截原因去调整WallFilter配置，不要盲目关闭防火墙功能。

8. 一个小技巧：如何确认Druid连接池的工作状态

最后分享一个实际运维中很实用的小技巧：通过JMX或者访问Druid的API接口来获取连接池状态，不用打开监控页面。

Druid暴露了一个/druid/datasource.json接口，登录监控页面后可以访问，返回JSON数据，包含当前连接池的所有指标：

curl -u monitor_ops:'你的密码' http://localhost:8080/druid/datasource.json

可以写个定时脚本，把这个接口的数据拉下来，接入现有的监控告警系统。比如活跃连接数超过max-active的80%就告警，慢SQL执行次数超过阈值就提醒。这样不需要人工盯着监控页面，异常情况自动发现，省心很多。

如果你用了Spring Boot Actuator，Druid的数据也可以暴露到Actuator的/actuator/metrics端点，这样就能和Prometheus、Grafana那套监控体系对接了。具体的对接方式需要再加依赖：

<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-3-starter</artifactId> <version>1.2.20</version> </dependency>

然后在application.yml里：

management: endpoints: web: exposure: include: metrics

实测下来，Druid在Spring Boot 3里的集成比2.x确实麻烦一点，但只要依赖坐标用对、参数配置准确，稳定性还是很高的。这套配置我用了小半年，监控数据一直正常，慢SQL日志帮我们抓到了好几个隐蔽的性能问题。后面如果涉及到多数据源的场景，Druid的配置链路会再复杂一些，到时候再单独写一篇。