简介面向Spring Boot初学者及整合实践者的完整示例包重点展示Spring Boot、MyBatis与Druid三者协同工作的整合流程。资源覆盖依赖引入、Druid数据源参数配置、会话工厂注册、映射器接口与XML映射文件编写、业务层注入调用等核心环节适用于需要快速搭建可运行数据访问层的开发场景也适合课程设计或内部培训时作为最小可运行模板参考。压缩包共93个文件以MyBatis映射XML为主另有Java源码与编译后的class字节码、配置文件、Maven工具脚本以及jar依赖等整体仅94KB结构精简易查阅。其中依赖清单已引入MyBatis与Druid的启动器配置文件设置了连接地址、用户名、密码及连接池初始化大小、最大活跃数、最大等待时间等参数XML映射文件则包含常见的查询映射示例便于按图索骥地对照整合步骤逐步学习。资源已有336人学习下载是典型的轻量级整合样例。通过该示例可掌握Spring Boot自动化配置与Druid连接池的基本使用方式理解SQL映射文件与映射器接口绑定的完整流程并可在其基础上扩展数据库连接池监控统计、多数据源或读写分离等高级能力。1. Spring Boot 整合 MyBatis 并接管 Druid 数据源这一套组合到底解决了什么做过 Java 后端的人几乎都绕不开这个组合Spring Boot 搭骨架、MyBatis 管 SQL、Druid 看连接和监控。很多人第一次接触是直接在配置文件里把spring.datasource.url一填启动时看到 Druid 的日志就以为“整合完了”但真的把项目推到测试环境后连接池参数怎么调、慢 SQL 去哪看、监控页为什么打不开这些问题全冒出来。这篇就围绕“Spring Boot 整合 MyBatis使用 Druid 数据源”这条主线把配置链路拆开讲清楚。适合刚用 Spring Boot 写服务、想把数据源从 HikariCP 换成 Druid 的开发者也适合已经在生产环境用着、但没细看过 Druid 各项指标的人——读完你能照着配出一套带监控、带连接池保护、带慢 SQL 拦截的完整数据访问层方案。2. 为什么选 Druid 而不是默认的 HikariCP连接池选型先想明白2.1 Spring Boot 默认数据源与 Druid 的定位差异Spring Boot 2.x 之后默认的数据源是 HikariCP这个选择本身没毛病HikariCP 性能好、字节码极简启动快对于大多数 CRUD 项目完全够用。但默认方案不等于最优方案。Druid 是阿里开源出来的连接池它的核心卖点不在“快”而在“看得见”——内置了 SQL 监控、慢 SQL 日志、防火墙过滤器、会话监控、Spring 关联监控等一整套能力。HikariCP 虽然也有 JMX 暴露但你要想在页面上直观地看每个 SQL 的执行次数、耗时分布、并发数曲线得另外接监控系统Druid 自带的stat视图打开即用。如果你的项目刚起步、SQL 简单、团队没有 DBAHikariCP 完全够但如果你要排查慢 SQL、要做数据源层面的限流和黑白名单、要给前端提供一份可交互的监控页Druid 的性价比就体现出来了。Druid 在 Spring Boot 里并不是一个“Starter 一加就完事”的东西它需要你自己定义配置类把DataSource对象交给 Spring 容器这个过程中埋了不少坑后面会逐个讲到。2.2 引入依赖的最小 POM版本冲突先掐死在源头常见的做法是引入druid-spring-boot-starter这个包帮你把自动配置做了大半但它和 Spring Boot 版本有兼容性要求。我一般不建议直接用官方的 starter而是用druid核心包加手动配置类原因有两个一是避免 starter 里配置项和 Spring Boot 自动配置冲突二是手动配置让每个参数落在明面上出问题时直接看配置就清楚。dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.2.20/version /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency逻辑说明这里刻意选了不带starter的 druid 包只依赖核心实现。mybatis-spring-boot-starter负责把 MyBatis 的SqlSessionFactory和 Spring 的DataSource桥接起来它会自动读取容器里的DataSourceBean。版本2.3.1对应 Spring Boot 2.x 系列如果你的项目是 Spring Boot 3.x需要把 MyBatis starter 换成mybatis-spring-boot-starter的 3.x 版本同时确保 druid 版本不低于 1.2.6否则 JDK 17 下可能遇到模块访问限制。2.3 为什么手动创建 DruidDataSource 而不是只靠 application.ymlSpring Boot 的DataSourceAutoConfiguration会在 classpath 下存在DataSource实现类时自动装配一个默认数据源。如果你同时引入了druid依赖且没有排除自动配置Spring Boot 可能会优先用HikariCP如果它也存在于 classpath或者因为找不到唯一候选而启动报错。更可控的做法是在配置类里显式声明DataSourceBean并用ConfigurationProperties绑定前缀这样配置来源清晰后续切换环境只改 yml。Configuration public class DruidDataSourceConfig { Bean ConfigurationProperties(prefix spring.datasource.druid) public DataSource druidDataSource() { return new DruidDataSource(); } }逻辑说明ConfigurationProperties(prefix spring.datasource.druid)会把 yml 里spring.datasource.druid下的键值自动映射到DruidDataSource的同名属性上省去手动 setter。注意这里没有调用DruidDataSource的初始化方法连接池的 lazy init 由第一次获取连接触发但对于生产环境我建议在afterPropertiesSet或PostConstruct阶段主动init()否则第一笔请求会多付出几十毫秒的连接初始化开销。3. 把数据库连接配置和 MyBatis 参数一次配到位3.1 YAML 配置模板Druid 连接池核心参数逐项解析Druid 的参数非常多但真正需要人工调的就那么十几个。下面这份配置覆盖了从连接池大小到监控开关的完整链路直接抄进application.yml即可每个参数后面我会说明取舍逻辑。spring: datasource: druid: url: jdbc:mysql://127.0.0.1:3306/test_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver 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-pool-prepared-statement-per-connection-size: 20 filters: stat,wall,slf4j connection-properties: druid.stat.mergeSqltrue;druid.stat.slowSqlMillis5000参数说明initial-size是启动时创建的物理连接数太小会导致高峰突然建连max-active20对大多数中小服务够用但如果接口 RT 都在百毫秒级且 QPS 上百这个值要上调到 50 并配合压测验证。max-wait60000是拿连接的超时时间超过直接抛异常避免线程无限阻塞。test-while-idletrue会在空闲连接被回收前用validation-query探活这是标准且推荐的做法。test-on-borrowfalse表示每次拿连接不额外探活减少一次网络往返如果你数据库网络抖动严重宁可把它设成 true 牺牲一点性能换稳定性。filtersstat,wall,slf4j这一段非常关键stat开启 SQL 监控统计wall开启 SQL 防火墙slf4j会把 SQL 执行情况输出到日志。3.2 MyBatis 配置驼峰映射、Mapper 扫描和分页插件数据源只管连接真正和 SQL 打交道的是 MyBatis。要让它和 Spring Boot 配合顺畅需要做三件事告诉 Spring 到哪里找 Mapper 接口、开启驼峰映射、注册分页插件。有一个很容易忽略的细节Spring Boot 2.x 的mybatis-spring-boot-starter默认不会自动扫描Mapper注解之外的接口除非你在启动类或配置类上加了MapperScan。Configuration MapperScan(com.example.demo.mapper) public class MyBatisConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(500L); interceptor.addInnerInterceptor(pagination); return interceptor; } Bean public ConfigurationCustomizer configurationCustomizer() { return configuration - configuration.setMapUnderscoreToCamelCase(true); } }逻辑说明MapperScan指定 Mapper 接口所在的包路径Spring 会为这些接口生成代理对象并注入到需要的地方。分页插件用MybatisPlusInterceptor是因为它同时兼容 MyBatis-Plus 和原生 MyBatis如果你项目里没引入 MyBatis-Plus直接使用这个拦截器仍然生效。setMaxLimit(500L)是给所有分页查询加一个上限保护防止前端传一个超大页码把数据库打垮。setMapUnderscoreToCamelCase(true)解决数据库字段user_name和 Java 属性userName的自动映射不开启的话你只能手动给每个字段写alias或者用Results非常痛苦。3.3 如何验证整合成功启动日志和最简单的查询测试配置全部完成后启动项目观察日志。Druid 初始化成功会打印类似于{dataSource-1} inited的日志MyBatis 会打印 Mapper 接口的注册信息。此时写一个最简单的查询来验证链路是否通了这一步能快速区分问题是出在连接池还是 Mapper 映射。RestController RequestMapping(/api/user) public class UserController { Autowired private UserMapper userMapper; GetMapping(/count) public Long count() { return userMapper.countAll(); } }!-- UserMapper.xml -- select idcountAll resultTypelong SELECT COUNT(*) FROM t_user /select逻辑说明countAll这个 SQL 不涉及任何字段映射是检验“数据源 MyBatis 连接”最干净的用例。如果接口返回正常说明 Druid 连接建立、MyBatis SqlSession 创建、Mapper 代理注入都工作正常。如果这一步报错优先查看配置前缀是否写错——spring.datasource.druid.url而不是spring.datasource.url这个低级错误占了初学阶段至少一半的启动失败案例。4. 连接池参数调优与监控配置别等线上告警才回头调参数4.1 max-active、min-idle 和 max-wait 怎么定才不算拍脑袋连接池参数没有万能公式但有一套相对科学的估算方式。先看两个指标接口平均 RT比如 200ms和峰值 QPS比如 300。单连接每秒能处理的请求数 1000ms / 200ms 5 个那么理论上需要的连接数 300 / 5 60 个。这是纯理论值实际还要叠加上数据库侧慢查询、网络抖动和 GC 停顿带来的等待放大效应所以每个连接的生产吞吐要打折建议按理论值的 1.5 到 2 倍配置 max-active。min-idle的意义在于兜底它保证即使长时间没有流量连接池里也保持一定数量的热连接避免突发流量瞬间建连把数据库打挂。max-wait60000是线程等待连接的超时如果你的连接池经常被占满日志里会出现wait millis 60000之类的关键字这说明要么 max-active 太小要么有连接泄漏没有被归还。用 Druid 的stat监控能看到当前活跃连接数这个指标长期接近 max-active 就要警惕了。4.2 慢 SQL 监控和 SQL 防火墙让问题暴露在用户投诉之前Druid 的statfilter 会把每个 SQL 的执行次数、总耗时、最大耗时、并发数记录下来slf4jfilter 则把这些数据输出到应用日志。我习惯把druid.stat.slowSqlMillis5000配置到连接属性里执行超过 5 秒的 SQL 会被单独标记并输出到慢 SQL 日志中。SQL 防火墙wall则是一个容易被低估的功能它能拦截select * without where、批量删除、不允许的语法类型等危险操作对生产环境是很好的双重保护。spring: datasource: druid: filter: wall: enabled: true config: delete-allow: true multi-statement-allow: false select-where-null-check: true参数说明multi-statement-allowfalse禁止一次执行多条 SQL防止注入select-where-null-checktrue要求查询必须带 where 条件除了全表 count。这两项在生产环境建议保持开启开发环境如果嫌麻烦可以临时关掉。但要注意wall 的规则再完善也只是第一道防线应用层的参数化查询依然是 SQL 注入防护的根本两者不冲突是互补关系。4.3 Druid Monitor 监控页Web 端可视化数据源状态Druid 自带的监控页是整合方案里最亮眼的部分它能够在线查看数据源列表、SQL 执行统计、Session 状态、URI 访问频率。要启用它需要注册一个ServletRegistrationBean指向StatViewServlet。这里有一个高频踩坑点很多人配了之后访问/druid/index.html是 404原因通常是 Spring Boot 对 Servlet 注册的路径匹配方式理解有误。Bean public ServletRegistrationBeanStatViewServlet statViewServletRegistration() { ServletRegistrationBeanStatViewServlet registration new ServletRegistrationBean(new StatViewServlet(), /druid/*); registration.addInitParameter(loginUsername, admin); registration.addInitParameter(loginPassword, admin123); registration.addInitParameter(resetEnable, false); registration.addInitParameter(allow, 127.0.0.1); return registration; }逻辑说明new StatViewServlet()这个构造器本身就是匿名内部类ServletRegistrationBean的第二个参数是 URL 映射模式必须写成/druid/*而不是/druid。allow127.0.0.1限制只有本机能访问监控页如果你在云服务器上部署需要把公司出口 IP 加进去。resetEnablefalse防止有人通过页面上的重置按钮把统计信息清空这个按钮对线上排查是致命的。另外还要注册一个WebStatFilter用于采集 Web 请求和 SQL 执行关联数据没有它监控页上 URI 和 SQL 的关联维度就是空的。5. 整合后必踩的坑环境隔离、连接泄漏和版本兼容问题5.1 现象本机能跑测试环境启动就报连接超时这是 Druid 整合项目里最经典的问题。本地开发连的是本机 MySQL到了测试环境连接的数据库往往在一个内网网段启动时 Druid 会在初始化阶段尝试建立initial-size: 5个连接。如果测试环境的数据库 IP 白名单没放通或者安全组规则挡了 3306 端口Druid 会反复重试直到max-wait超时。原因分析连接池初始化失败后Spring 容器启动会因为这个 Bean 创建失败而整体失败。很多人误以为是代码问题反复检查 Mapper 和配置实际是网络层没通。解决思路是先在部署机上用命令行工具直接测试数据库连通性确认能连通后再启动服务。如果是云环境还要检查数据库实例是否开了“仅内网访问”之类的限制外网 IP 可能根本不在允许列表里。5.2 现象连接池被耗尽应用“假死”但没有 SQL 报错这种情况最为隐蔽——日志里没有 SQL 语法错误服务还能收到请求但所有请求都在获取连接时卡住超时后抛GetConnectionTimeoutException。背后通常有两种原因一是某个事务里connection被拿到后因为异常路径没有释放二是连接池的max-active配置过大数据库自身连接数超过了上限导致新连接建不起来。解决思路首先在 Druid 监控页看“活跃连接数”是不是长期贴近max-active。然后检查项目里有没有类似try { conn dataSource.getConnection(); } catch (Exception e) { // 没有归还 conn }的代码。如果用的是 Spring 的Transactional大多数情况下事务管理器会帮你归还连接但如果你手写了原生 JDBC 代码、又混用了 MyBatis 的SqlSessionTemplate就很容易出现一个事务里同时存在多条连接没有释放。记得在退出事务前统一用finally { if (conn ! null) conn.close(); }。注意这里的close()对 Druid 而言是归还连接池不是真的关闭物理连接。5.3 现象本地启动时报Failed to determine a suitable driver class这个报错信息在 Spring Boot 整合 Druid 时非常高频。原因是你配置了spring.datasource.url但没有配置driver-class-nameSpring Boot 会尝试从 URL 推断驱动类型。对于 MySQL 8.x 来说如果使用com.mysql.jdbc.Driver这个旧驱动类名启动会报错正确写法是com.mysql.cj.jdbc.Driver。同时 MongoDB 或 NoSQL 场景也会有类似的报错但如果你根本没有引入对应的驱动、却在 yml 里配置了多余的spring.data.mongodb等字段也可能触发这个错误。还有一个非常隐蔽的坑当你的DataSourceBean 用ConfigurationProperties(prefix spring.datasource.druid)绑定时Spring Boot 自带的DataSourceAutoConfiguration可能仍然在尝试参与装配。你若在排除配置时写错了类名比如写成了DataSourceAutoConfiguration.class却忘记排除DataSourceTransactionManagerAutoConfiguration事务管理器会拿着未知类型的数据源去初始化而报错。推荐的做法是使用SpringBootApplication(exclude {DataSourceAutoConfiguration.class})如果项目里不需要自动配置的事务管理器一并排除。6. 整合后的进阶验证如何确认 Druid 监控数据和 SQL 执行是真实可用的最后一环是验证。启动项目后打开监控页你会看到数据源列表里有一行记录包含初始连接数、最大连接数、活跃连接数等指标。此时做一次压测或者连续调用接口观察 SQL 监控标签页里是否出现了相应的 SELECT 记录并核对执行时间(ms)和执行次数是否符合预期。这里有三个我验证过很多次的经验点第一个经验点是确认StatFilter合并统计是否生效。你在connection-properties里配置了druid.stat.mergeSqltrue后同一条 SQL 即使参数不同也会被合并为一条统计记录方便整体评估这条 SQL 的耗时。如果你发现监控页上出现了成百上千条几乎一模一样的 SQL 记录多半是mergeSql没有生效检查配置项拼写。第二个经验点是 Wall filter 的日志输出。开启wall后并不是每次执行 SQL 都会打印拦截日志只有当 SQL 触发拦截规则时才会有 WARN 级别日志。你可以在测试环境故意执行一条没有 where 条件的 SQL确认日志里是否输出拦截信息。如果没有输出检查filter.wall.enabled是不是被后续的配置文件覆盖了。第三个经验点是连接池回收的时间设置。time-between-eviction-runs-millis60000控制的是每隔 60 秒检测一次空闲连接min-evictable-idle-time-millis300000表示连接空闲超过 5 分钟后会被回收。如果应用有凌晨低峰期第二天早上出现首次访问慢的情况可以把min-evictable-idle-time-millis调大到 600000或者让initial-size保持一个较高值。这个节奏需要根据自己的业务场景实测没有绝对正确的参数。我自己在多个模拟项目 X 和某跨平台系统里反复验证过这套方案最大的教训是Druid 不是“加上就完事”的组件它给了你监控能力你就得真的去看那些数字。很多人配完以后从不打开监控页等到用户反馈接口慢才上去看那时才发现某条 SQL 执行了 3 秒、连接池活跃数长期 80% 以上。如果你也准备在下一套系统里用 Spring Boot 整合 MyBatis 和 Druid记住把这些参数在联调阶段就定下来用压测数据反向调整而不是等上线后靠直觉猜。希望帮到你。本文还有配套的精品资源点击获取
简介面向Spring Boot初学者及整合实践者的完整示例包重点展示Spring Boot、MyBatis与Druid三者协同工作的整合流程。资源覆盖依赖引入、Druid数据源参数配置、会话工厂注册、映射器接口与XML映射文件编写、业务层注入调用等核心环节适用于需要快速搭建可运行数据访问层的开发场景也适合课程设计或内部培训时作为最小可运行模板参考。压缩包共93个文件以MyBatis映射XML为主另有Java源码与编译后的class字节码、配置文件、Maven工具脚本以及jar依赖等整体仅94KB结构精简易查阅。其中依赖清单已引入MyBatis与Druid的启动器配置文件设置了连接地址、用户名、密码及连接池初始化大小、最大活跃数、最大等待时间等参数XML映射文件则包含常见的查询映射示例便于按图索骥地对照整合步骤逐步学习。资源已有336人学习下载是典型的轻量级整合样例。通过该示例可掌握Spring Boot自动化配置与Druid连接池的基本使用方式理解SQL映射文件与映射器接口绑定的完整流程并可在其基础上扩展数据库连接池监控统计、多数据源或读写分离等高级能力。1. Spring Boot 整合 MyBatis 并接管 Druid 数据源这一套组合到底解决了什么做过 Java 后端的人几乎都绕不开这个组合Spring Boot 搭骨架、MyBatis 管 SQL、Druid 看连接和监控。很多人第一次接触是直接在配置文件里把spring.datasource.url一填启动时看到 Druid 的日志就以为“整合完了”但真的把项目推到测试环境后连接池参数怎么调、慢 SQL 去哪看、监控页为什么打不开这些问题全冒出来。这篇就围绕“Spring Boot 整合 MyBatis使用 Druid 数据源”这条主线把配置链路拆开讲清楚。适合刚用 Spring Boot 写服务、想把数据源从 HikariCP 换成 Druid 的开发者也适合已经在生产环境用着、但没细看过 Druid 各项指标的人——读完你能照着配出一套带监控、带连接池保护、带慢 SQL 拦截的完整数据访问层方案。2. 为什么选 Druid 而不是默认的 HikariCP连接池选型先想明白2.1 Spring Boot 默认数据源与 Druid 的定位差异Spring Boot 2.x 之后默认的数据源是 HikariCP这个选择本身没毛病HikariCP 性能好、字节码极简启动快对于大多数 CRUD 项目完全够用。但默认方案不等于最优方案。Druid 是阿里开源出来的连接池它的核心卖点不在“快”而在“看得见”——内置了 SQL 监控、慢 SQL 日志、防火墙过滤器、会话监控、Spring 关联监控等一整套能力。HikariCP 虽然也有 JMX 暴露但你要想在页面上直观地看每个 SQL 的执行次数、耗时分布、并发数曲线得另外接监控系统Druid 自带的stat视图打开即用。如果你的项目刚起步、SQL 简单、团队没有 DBAHikariCP 完全够但如果你要排查慢 SQL、要做数据源层面的限流和黑白名单、要给前端提供一份可交互的监控页Druid 的性价比就体现出来了。Druid 在 Spring Boot 里并不是一个“Starter 一加就完事”的东西它需要你自己定义配置类把DataSource对象交给 Spring 容器这个过程中埋了不少坑后面会逐个讲到。2.2 引入依赖的最小 POM版本冲突先掐死在源头常见的做法是引入druid-spring-boot-starter这个包帮你把自动配置做了大半但它和 Spring Boot 版本有兼容性要求。我一般不建议直接用官方的 starter而是用druid核心包加手动配置类原因有两个一是避免 starter 里配置项和 Spring Boot 自动配置冲突二是手动配置让每个参数落在明面上出问题时直接看配置就清楚。dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.2.20/version /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency逻辑说明这里刻意选了不带starter的 druid 包只依赖核心实现。mybatis-spring-boot-starter负责把 MyBatis 的SqlSessionFactory和 Spring 的DataSource桥接起来它会自动读取容器里的DataSourceBean。版本2.3.1对应 Spring Boot 2.x 系列如果你的项目是 Spring Boot 3.x需要把 MyBatis starter 换成mybatis-spring-boot-starter的 3.x 版本同时确保 druid 版本不低于 1.2.6否则 JDK 17 下可能遇到模块访问限制。2.3 为什么手动创建 DruidDataSource 而不是只靠 application.ymlSpring Boot 的DataSourceAutoConfiguration会在 classpath 下存在DataSource实现类时自动装配一个默认数据源。如果你同时引入了druid依赖且没有排除自动配置Spring Boot 可能会优先用HikariCP如果它也存在于 classpath或者因为找不到唯一候选而启动报错。更可控的做法是在配置类里显式声明DataSourceBean并用ConfigurationProperties绑定前缀这样配置来源清晰后续切换环境只改 yml。Configuration public class DruidDataSourceConfig { Bean ConfigurationProperties(prefix spring.datasource.druid) public DataSource druidDataSource() { return new DruidDataSource(); } }逻辑说明ConfigurationProperties(prefix spring.datasource.druid)会把 yml 里spring.datasource.druid下的键值自动映射到DruidDataSource的同名属性上省去手动 setter。注意这里没有调用DruidDataSource的初始化方法连接池的 lazy init 由第一次获取连接触发但对于生产环境我建议在afterPropertiesSet或PostConstruct阶段主动init()否则第一笔请求会多付出几十毫秒的连接初始化开销。3. 把数据库连接配置和 MyBatis 参数一次配到位3.1 YAML 配置模板Druid 连接池核心参数逐项解析Druid 的参数非常多但真正需要人工调的就那么十几个。下面这份配置覆盖了从连接池大小到监控开关的完整链路直接抄进application.yml即可每个参数后面我会说明取舍逻辑。spring: datasource: druid: url: jdbc:mysql://127.0.0.1:3306/test_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver 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-pool-prepared-statement-per-connection-size: 20 filters: stat,wall,slf4j connection-properties: druid.stat.mergeSqltrue;druid.stat.slowSqlMillis5000参数说明initial-size是启动时创建的物理连接数太小会导致高峰突然建连max-active20对大多数中小服务够用但如果接口 RT 都在百毫秒级且 QPS 上百这个值要上调到 50 并配合压测验证。max-wait60000是拿连接的超时时间超过直接抛异常避免线程无限阻塞。test-while-idletrue会在空闲连接被回收前用validation-query探活这是标准且推荐的做法。test-on-borrowfalse表示每次拿连接不额外探活减少一次网络往返如果你数据库网络抖动严重宁可把它设成 true 牺牲一点性能换稳定性。filtersstat,wall,slf4j这一段非常关键stat开启 SQL 监控统计wall开启 SQL 防火墙slf4j会把 SQL 执行情况输出到日志。3.2 MyBatis 配置驼峰映射、Mapper 扫描和分页插件数据源只管连接真正和 SQL 打交道的是 MyBatis。要让它和 Spring Boot 配合顺畅需要做三件事告诉 Spring 到哪里找 Mapper 接口、开启驼峰映射、注册分页插件。有一个很容易忽略的细节Spring Boot 2.x 的mybatis-spring-boot-starter默认不会自动扫描Mapper注解之外的接口除非你在启动类或配置类上加了MapperScan。Configuration MapperScan(com.example.demo.mapper) public class MyBatisConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(500L); interceptor.addInnerInterceptor(pagination); return interceptor; } Bean public ConfigurationCustomizer configurationCustomizer() { return configuration - configuration.setMapUnderscoreToCamelCase(true); } }逻辑说明MapperScan指定 Mapper 接口所在的包路径Spring 会为这些接口生成代理对象并注入到需要的地方。分页插件用MybatisPlusInterceptor是因为它同时兼容 MyBatis-Plus 和原生 MyBatis如果你项目里没引入 MyBatis-Plus直接使用这个拦截器仍然生效。setMaxLimit(500L)是给所有分页查询加一个上限保护防止前端传一个超大页码把数据库打垮。setMapUnderscoreToCamelCase(true)解决数据库字段user_name和 Java 属性userName的自动映射不开启的话你只能手动给每个字段写alias或者用Results非常痛苦。3.3 如何验证整合成功启动日志和最简单的查询测试配置全部完成后启动项目观察日志。Druid 初始化成功会打印类似于{dataSource-1} inited的日志MyBatis 会打印 Mapper 接口的注册信息。此时写一个最简单的查询来验证链路是否通了这一步能快速区分问题是出在连接池还是 Mapper 映射。RestController RequestMapping(/api/user) public class UserController { Autowired private UserMapper userMapper; GetMapping(/count) public Long count() { return userMapper.countAll(); } }!-- UserMapper.xml -- select idcountAll resultTypelong SELECT COUNT(*) FROM t_user /select逻辑说明countAll这个 SQL 不涉及任何字段映射是检验“数据源 MyBatis 连接”最干净的用例。如果接口返回正常说明 Druid 连接建立、MyBatis SqlSession 创建、Mapper 代理注入都工作正常。如果这一步报错优先查看配置前缀是否写错——spring.datasource.druid.url而不是spring.datasource.url这个低级错误占了初学阶段至少一半的启动失败案例。4. 连接池参数调优与监控配置别等线上告警才回头调参数4.1 max-active、min-idle 和 max-wait 怎么定才不算拍脑袋连接池参数没有万能公式但有一套相对科学的估算方式。先看两个指标接口平均 RT比如 200ms和峰值 QPS比如 300。单连接每秒能处理的请求数 1000ms / 200ms 5 个那么理论上需要的连接数 300 / 5 60 个。这是纯理论值实际还要叠加上数据库侧慢查询、网络抖动和 GC 停顿带来的等待放大效应所以每个连接的生产吞吐要打折建议按理论值的 1.5 到 2 倍配置 max-active。min-idle的意义在于兜底它保证即使长时间没有流量连接池里也保持一定数量的热连接避免突发流量瞬间建连把数据库打挂。max-wait60000是线程等待连接的超时如果你的连接池经常被占满日志里会出现wait millis 60000之类的关键字这说明要么 max-active 太小要么有连接泄漏没有被归还。用 Druid 的stat监控能看到当前活跃连接数这个指标长期接近 max-active 就要警惕了。4.2 慢 SQL 监控和 SQL 防火墙让问题暴露在用户投诉之前Druid 的statfilter 会把每个 SQL 的执行次数、总耗时、最大耗时、并发数记录下来slf4jfilter 则把这些数据输出到应用日志。我习惯把druid.stat.slowSqlMillis5000配置到连接属性里执行超过 5 秒的 SQL 会被单独标记并输出到慢 SQL 日志中。SQL 防火墙wall则是一个容易被低估的功能它能拦截select * without where、批量删除、不允许的语法类型等危险操作对生产环境是很好的双重保护。spring: datasource: druid: filter: wall: enabled: true config: delete-allow: true multi-statement-allow: false select-where-null-check: true参数说明multi-statement-allowfalse禁止一次执行多条 SQL防止注入select-where-null-checktrue要求查询必须带 where 条件除了全表 count。这两项在生产环境建议保持开启开发环境如果嫌麻烦可以临时关掉。但要注意wall 的规则再完善也只是第一道防线应用层的参数化查询依然是 SQL 注入防护的根本两者不冲突是互补关系。4.3 Druid Monitor 监控页Web 端可视化数据源状态Druid 自带的监控页是整合方案里最亮眼的部分它能够在线查看数据源列表、SQL 执行统计、Session 状态、URI 访问频率。要启用它需要注册一个ServletRegistrationBean指向StatViewServlet。这里有一个高频踩坑点很多人配了之后访问/druid/index.html是 404原因通常是 Spring Boot 对 Servlet 注册的路径匹配方式理解有误。Bean public ServletRegistrationBeanStatViewServlet statViewServletRegistration() { ServletRegistrationBeanStatViewServlet registration new ServletRegistrationBean(new StatViewServlet(), /druid/*); registration.addInitParameter(loginUsername, admin); registration.addInitParameter(loginPassword, admin123); registration.addInitParameter(resetEnable, false); registration.addInitParameter(allow, 127.0.0.1); return registration; }逻辑说明new StatViewServlet()这个构造器本身就是匿名内部类ServletRegistrationBean的第二个参数是 URL 映射模式必须写成/druid/*而不是/druid。allow127.0.0.1限制只有本机能访问监控页如果你在云服务器上部署需要把公司出口 IP 加进去。resetEnablefalse防止有人通过页面上的重置按钮把统计信息清空这个按钮对线上排查是致命的。另外还要注册一个WebStatFilter用于采集 Web 请求和 SQL 执行关联数据没有它监控页上 URI 和 SQL 的关联维度就是空的。5. 整合后必踩的坑环境隔离、连接泄漏和版本兼容问题5.1 现象本机能跑测试环境启动就报连接超时这是 Druid 整合项目里最经典的问题。本地开发连的是本机 MySQL到了测试环境连接的数据库往往在一个内网网段启动时 Druid 会在初始化阶段尝试建立initial-size: 5个连接。如果测试环境的数据库 IP 白名单没放通或者安全组规则挡了 3306 端口Druid 会反复重试直到max-wait超时。原因分析连接池初始化失败后Spring 容器启动会因为这个 Bean 创建失败而整体失败。很多人误以为是代码问题反复检查 Mapper 和配置实际是网络层没通。解决思路是先在部署机上用命令行工具直接测试数据库连通性确认能连通后再启动服务。如果是云环境还要检查数据库实例是否开了“仅内网访问”之类的限制外网 IP 可能根本不在允许列表里。5.2 现象连接池被耗尽应用“假死”但没有 SQL 报错这种情况最为隐蔽——日志里没有 SQL 语法错误服务还能收到请求但所有请求都在获取连接时卡住超时后抛GetConnectionTimeoutException。背后通常有两种原因一是某个事务里connection被拿到后因为异常路径没有释放二是连接池的max-active配置过大数据库自身连接数超过了上限导致新连接建不起来。解决思路首先在 Druid 监控页看“活跃连接数”是不是长期贴近max-active。然后检查项目里有没有类似try { conn dataSource.getConnection(); } catch (Exception e) { // 没有归还 conn }的代码。如果用的是 Spring 的Transactional大多数情况下事务管理器会帮你归还连接但如果你手写了原生 JDBC 代码、又混用了 MyBatis 的SqlSessionTemplate就很容易出现一个事务里同时存在多条连接没有释放。记得在退出事务前统一用finally { if (conn ! null) conn.close(); }。注意这里的close()对 Druid 而言是归还连接池不是真的关闭物理连接。5.3 现象本地启动时报Failed to determine a suitable driver class这个报错信息在 Spring Boot 整合 Druid 时非常高频。原因是你配置了spring.datasource.url但没有配置driver-class-nameSpring Boot 会尝试从 URL 推断驱动类型。对于 MySQL 8.x 来说如果使用com.mysql.jdbc.Driver这个旧驱动类名启动会报错正确写法是com.mysql.cj.jdbc.Driver。同时 MongoDB 或 NoSQL 场景也会有类似的报错但如果你根本没有引入对应的驱动、却在 yml 里配置了多余的spring.data.mongodb等字段也可能触发这个错误。还有一个非常隐蔽的坑当你的DataSourceBean 用ConfigurationProperties(prefix spring.datasource.druid)绑定时Spring Boot 自带的DataSourceAutoConfiguration可能仍然在尝试参与装配。你若在排除配置时写错了类名比如写成了DataSourceAutoConfiguration.class却忘记排除DataSourceTransactionManagerAutoConfiguration事务管理器会拿着未知类型的数据源去初始化而报错。推荐的做法是使用SpringBootApplication(exclude {DataSourceAutoConfiguration.class})如果项目里不需要自动配置的事务管理器一并排除。6. 整合后的进阶验证如何确认 Druid 监控数据和 SQL 执行是真实可用的最后一环是验证。启动项目后打开监控页你会看到数据源列表里有一行记录包含初始连接数、最大连接数、活跃连接数等指标。此时做一次压测或者连续调用接口观察 SQL 监控标签页里是否出现了相应的 SELECT 记录并核对执行时间(ms)和执行次数是否符合预期。这里有三个我验证过很多次的经验点第一个经验点是确认StatFilter合并统计是否生效。你在connection-properties里配置了druid.stat.mergeSqltrue后同一条 SQL 即使参数不同也会被合并为一条统计记录方便整体评估这条 SQL 的耗时。如果你发现监控页上出现了成百上千条几乎一模一样的 SQL 记录多半是mergeSql没有生效检查配置项拼写。第二个经验点是 Wall filter 的日志输出。开启wall后并不是每次执行 SQL 都会打印拦截日志只有当 SQL 触发拦截规则时才会有 WARN 级别日志。你可以在测试环境故意执行一条没有 where 条件的 SQL确认日志里是否输出拦截信息。如果没有输出检查filter.wall.enabled是不是被后续的配置文件覆盖了。第三个经验点是连接池回收的时间设置。time-between-eviction-runs-millis60000控制的是每隔 60 秒检测一次空闲连接min-evictable-idle-time-millis300000表示连接空闲超过 5 分钟后会被回收。如果应用有凌晨低峰期第二天早上出现首次访问慢的情况可以把min-evictable-idle-time-millis调大到 600000或者让initial-size保持一个较高值。这个节奏需要根据自己的业务场景实测没有绝对正确的参数。我自己在多个模拟项目 X 和某跨平台系统里反复验证过这套方案最大的教训是Druid 不是“加上就完事”的组件它给了你监控能力你就得真的去看那些数字。很多人配完以后从不打开监控页等到用户反馈接口慢才上去看那时才发现某条 SQL 执行了 3 秒、连接池活跃数长期 80% 以上。如果你也准备在下一套系统里用 Spring Boot 整合 MyBatis 和 Druid记住把这些参数在联调阶段就定下来用压测数据反向调整而不是等上线后靠直觉猜。希望帮到你。本文还有配套的精品资源点击获取
