1. 项目概述与核心价值最近在做一个国产化适配的项目数据库从Oracle换成了达梦8应用框架还是基于Spring Boot那一套。数据库连接池这块团队里一直用的都是阿里的Druid稳定、监控功能强大大家都用顺手了。但真到了要配达梦的时候发现网上现成的、能直接“抄作业”的完整配置说明还真不多大多都是只言片语或者还停留在老版本。踩了几个坑调优了几轮之后总算把Druid和达梦8搭配得比较稳了。今天就把从驱动引入、基础配置、到监控集成、再到生产环境调优这一整套实操过程梳理出来如果你也在做类似的技术选型或迁移这篇内容应该能帮你省下不少排查的时间。简单来说Druid连接池配达梦8核心就解决几个事第一让Spring Boot应用能正确识别并加载达梦的JDBC驱动第二配置出一套性能达标、稳定可靠的连接池参数避免连接泄露和性能瓶颈第三把Druid强大的监控能力用起来方便我们随时洞察数据库连接的健康状况。这不仅仅是改个driver-class-name那么简单里面涉及到驱动版本兼容、SQL解析、监控项适配等一系列细节。2. 环境准备与依赖引入2.1 达梦8 JDBC驱动获取与选择达梦数据库的JDBC驱动不像MySQL、PostgreSQL那样可以直接从Maven中央仓库拉取。你需要从达梦的官方网站下载对应的驱动包。这里有个关键点一定要确认你下载的驱动版本与你的达梦数据库服务器版本匹配。通常达梦8会提供Dm8JdbcDriver18.jar这样的驱动包。我建议直接使用达梦安装目录下的/drivers/jdbc目录中的jar包这是最稳妥的。拿到jar包后你有两种方式引入项目本地安装到Maven仓库这是团队协作时的推荐做法可以保证所有开发者环境一致。mvn install:install-file -DfileD:/你的路径/Dm8JdbcDriver18.jar -DgroupIdcom.dameng -DartifactIdDm8JdbcDriver18 -Dversion8.1.3.62 -Dpackagingjar执行后就可以在pom.xml中像引用普通依赖一样引用它了。直接放入项目lib目录对于简单项目或快速验证可以将jar包放入项目的src/main/resources/lib目录然后在pom.xml中通过system作用域引入。但这种方式不利于依赖管理和持续集成生产环境慎用。在pom.xml中除了达梦驱动核心就是引入Druid的Spring Boot Starter它能帮我们省去大量繁琐的Bean配置。dependencies !-- 达梦8 JDBC驱动 (需先本地安装) -- dependency groupIdcom.dameng/groupId artifactIdDm8JdbcDriver18/artifactId version8.1.3.62/version !-- 版本号请替换为你实际使用的 -- /dependency !-- Druid连接池Spring Boot Starter -- dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.20/version !-- 建议使用较新稳定版 -- /dependency !-- 其他Spring Boot依赖如Web、JPA/MyBatis等 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId !-- 或用MyBatis -- /dependency /dependencies注意达梦驱动的groupId和artifactId没有统一标准上述com.dameng:Dm8JdbcDriver18是我安装时使用的你需要根据自己安装时定义的坐标进行修改。版本号也务必与数据库服务端版本对应否则可能出现兼容性问题。2.2 基础配置文件解析接下来是重头戏application.yml或application.properties的配置。这里我会把配置项分成“连接基础”、“连接池核心参数”、“监控与防御”三块来详细说明。spring: datasource: # 1. 连接基础信息 driver-class-name: dm.jdbc.driver.DmDriver # 达梦8驱动类名 url: jdbc:dm://192.168.1.100:5236/DAMENG?schema你的模式名zeroDateTimeBehaviorconvertToNulluseUnicodetruecharacterEncodingutf-8 username: YOUR_USERNAME password: YOUR_PASSWORD type: com.alibaba.druid.pool.DruidDataSource # 指定使用Druid数据源 # 2. Druid连接池专属配置 (使用druid前缀) druid: # 2.1 连接池大小控制 (根据实际负载调整) initial-size: 5 min-idle: 5 max-active: 20 # 获取连接超时时间毫秒网络不好或池满时很重要 max-wait: 60000 # 2.2 连接有效性检测 validation-query: SELECT 1 FROM DUAL # 达梦的检测SQL test-while-idle: true # 建议开启定时检测空闲连接 test-on-borrow: false # 取用时检测高并发下影响性能不建议开 test-on-return: false # 归还时检测通常不需要 time-between-eviction-runs-millis: 60000 # 检测线程运行间隔 min-evictable-idle-time-millis: 300000 # 连接最小空闲时间超时可能被回收 # 2.3 防御性配置 filters: stat,wall,log4j2 # 启用统计、防御SQL注入、日志过滤器 connection-properties: druid.stat.mergeSqltrue;druid.stat.slowSqlMillis5000 # 合并统计慢SQL阈值5秒 web-stat-filter: enabled: true url-pattern: /* exclusions: *.js,*.gif,*.jpg,*.png,*.css,*.ico,/druid/* stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin # 生产环境务必修改 login-password: admin # 生产环境务必修改 reset-enable: false # 禁用重置按钮防止误操作关键配置点解读driver-class-name达梦8的驱动类固定为dm.jdbc.driver.DmDriver不要写错。url参数jdbc:dm://是协议头5236是达梦默认端口DAMENG是数据库名schema参数通常需要指定尤其是你的用户不是SYSDBA时。后面的zeroDateTimeBehavior等参数是借鉴MySQL的习惯达梦可能不完全支持但加了通常无害核心是前面部分。validation-query这是最容易出错的地方之一。达梦数据库的连通性测试SQL是SELECT 1 FROM DUAL。如果写成MySQL的SELECT 1Druid会在后台日志疯狂报错导致连接检测失败最终连接池无法正常工作。filtersstat用于统计监控wall用于防御SQL注入对达梦支持度需验证log4j2或slf4j用于输出日志。如果你发现wall过滤器导致某些合法SQL被拦截可以考虑暂时移除但要做好应用层SQL注入的防护。stat-view-servlet这是Druid内置的监控台通过/druid路径访问。生产环境下login-username和login-password必须修改为强密码并且最好通过网络策略限制访问IP避免暴露数据库信息。3. 高级配置与生产调优基础配置能让应用跑起来但要在生产环境稳定运行还需要进行一系列调优。这部分配置往往没有标准答案需要根据你的业务压力、数据库性能和应用特点来调整。3.1 连接池参数深度调优连接池参数设置不合理要么导致数据库连接数耗尽要么造成大量资源浪费。下面这个表格是我根据一个中等并发量的Web应用总结的调优思路参数名默认值/初始值调优建议与说明不当设置的后果initial-size0建议设置为与min-idle相同如5。应用启动时即建立少量连接避免首次请求的延迟。设为0时首个请求需要等待连接创建影响响应速度。min-idle0核心参数。建议设置为max-active的1/4到1/2如5-10。保证始终有“热”连接可用。设置过小突发流量时需频繁创建连接增加数据库负担和延迟设置过大浪费资源。max-active8核心参数。根据数据库max_connections和应用线程池大小设定。一个经验公式应用容器线程数 * 2或数据库最大连接数 - 10预留管理连接。通常20-50起步。设置过小高并发时大量线程等待连接导致请求堆积、超时设置过大可能压垮数据库。max-wait-1无限等待建议设置一个合理值如3000030秒。当池中无可用连接时申请连接的线程最长等待时间。-1可能导致线程无限期挂起使应用无响应。设置过短在流量峰值时可能抛出大量获取连接超时异常。time-between-eviction-runs-millis60000 (1分钟)空闲连接检测线程的运行间隔。保持1分钟即可过于频繁消耗CPU。间隔太长无效连接不能及时回收间隔太短无谓消耗系统资源。min-evictable-idle-time-millis1800000 (30分钟)连接在池中最小空闲生存时间超时可能被回收。可根据应用访问的波峰波谷调整如业务低峰期长的可设为30分钟。设置过短可能导致连接被频繁销毁和创建失去连接池意义。调优心得最关键的max-active和min-idle需要结合监控来定。先设置一个保守值然后通过Druid监控台观察“活跃连接数”峰值和“等待线程数”。如果经常有等待线程说明max-active可能不够如果“空闲连接数”长期远大于min-idle可以考虑适当调小min-idle。3.2 连接泄漏排查与监控强化连接泄漏是线上系统最常见的问题之一表现就是连接数缓慢增长直到耗尽。Druid提供了强大的工具来定位泄漏。首先确保你的filters配置包含了stat。然后在配置中开启连接泄漏检测spring: datasource: druid: # ... 其他配置 remove-abandoned: true # 是否移除泄露的连接 remove-abandoned-timeout: 300 # 泄露连接被移除的超时时间秒即一个连接被占用超过此时间视为泄露 log-abandoned: true # 是否记录泄露连接的堆栈信息当配置了remove-abandoned后Druid会跟踪每一个借出的连接。如果一个连接被应用程序获取后超过remove-abandoned-timeout例如300秒仍未归还Druid会认为它发生了泄漏并强制将其回收同时如果log-abandoned为true会在日志中打印出该连接被获取时的调用堆栈信息。如何利用这个功能当你在监控台发现“连接持有时间”分布中有大量超长如超过300秒的连接时就要警惕了。去应用日志通常是warn或error级别中搜索abandoned connection关键词你会看到类似下面的日志其中包含了完整的堆栈能直接定位到是哪段代码没有正确关闭连接比如忘了在finally块中关闭Connection、Statement或ResultSet。WARN - abandon connection, owner thread: http-nio-8080-exec-5, connected at: Tue Nov 01 14:00:00 CST 2023, open stackTrace at java.lang.Thread.getStackTrace(Thread.java:1559) at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:1388) ... [你的业务代码调用路径]3.3 集成MyBatis或JPA的特别注意事项如果你使用MyBatis确保在SqlSessionFactoryBean中正确设置了dataSource这通常由mybatis-spring-boot-starter自动完成但如果你有自定义配置需要检查。重点在于Druid连接池本身与MyBatis没有直接冲突。如果使用Spring Data JPA需要关注Hibernate的连接释放策略。默认情况下Hibernate会在事务结束后释放连接回池。但如果你在非事务环境下操作或者使用了open-in-view模式Spring Boot默认可能开启连接持有时间会变长。建议在application.yml中明确配置spring: jpa: open-in-view: false # 建议关闭避免请求处理期间一直占用连接 properties: hibernate: connection: release_mode: after_transaction # 事务结束后释放连接4. 监控台使用与问题诊断配置好stat-view-servlet后启动应用访问http://你的应用地址:端口/druid/index.html输入配置的用户名密码即可进入Druid监控台。这里是我们诊断数据库连接问题的“仪表盘”。4.1 核心监控指标解读进入首页你会看到数据源、SQL、Web应用等多个标签页。对于连接池问题重点关注“数据源”页等待线程数如果这个数字长期大于0甚至持续增长是max-active设置过小的最直接证据。应用线程在排队等待获取数据库连接。活跃连接数当前正在被使用的连接数。它应该随着请求波动最高点不应持续接近max-active。如果长期顶到最大值说明连接池大小可能成为瓶颈。空闲连接数池中可用的连接数。它应该在min-idle上下波动。如果长期为0说明min-idle可能设低了或者max-active不够用连接被借出后没有空闲的。连接持有时间分布这个图表非常有用。它展示了连接从被取走到归还所花费的时间。一个健康的系统大部分连接的持有时间应该在毫秒到秒级。如果出现大量长达几分钟甚至更久的“长连接”极有可能发生了连接泄漏需要立刻用前面提到的log-abandoned功能排查。PS Cache Hit RatioPrepared Statement缓存命中率对于使用预编译语句MyBatis默认是的应用这个比率越高越好。如果很低可以考虑适当调大druid.max-pool-prepared-statement-per-connection-size参数但注意会增加内存开销。4.2 SQL监控与慢查询定位在“SQL监控”页Druid记录了所有执行过的SQL并提供了执行次数、总时间、最慢、并发最大等关键数据。找到慢SQL直接按“执行时间”排序排在前面的就是你的性能瓶颈。点击SQL语句还能看到其具体的执行历史。分析SQL模式关注“读取行数”和“更新行数”巨大的SQL。达梦数据库对复杂查询的优化可能与Oracle/MySQL不同可能需要针对性添加索引或改写SQL。识别频繁查询按“执行次数”排序看看是否有可以缓存的查询结果用应用缓存如Redis来减轻数据库压力。一个实操技巧在测试环境你可以将druid.filter.stat.log-slow-sql设置为true并将druid.filter.stat.slow-sql-millis设为一个较低的值如100毫秒。这样所有慢SQL都会在应用日志中打印出来方便结合业务日志上下文进行分析比在监控台手动筛选更高效。5. 常见问题与排查实录在实际配置和运维过程中我遇到了不少典型问题这里列出来供大家参考。5.1 驱动类找不到ClassNotFoundException问题现象应用启动失败报错java.lang.ClassNotFoundException: dm.jdbc.driver.DmDriver。排查步骤检查依赖首先确认pom.xml中达梦驱动的依赖是否正确引入。运行mvn dependency:tree | grep dameng查看依赖树中是否存在。检查包路径如果使用system作用域引入本地jar检查路径是否正确并且确认打包如打jar或war时该jar包是否被包含进去。对于Spring Boot可执行jarsystem作用域的依赖默认不会被打包这是最常见的坑强烈建议使用mvn install安装到本地仓库。检查驱动类名确认driver-class-name拼写完全正确是dm.jdbc.driver.DmDriver。5.2 连接测试失败Validation-Query错误问题现象应用启动看似成功但日志中不断出现validationQuery执行错误或者在使用过程中偶尔出现连接不可用的异常。排查步骤确认SQL语法百分之九十的问题出在validation-query上。确保你写的是达梦数据库支持的语法SELECT 1 FROM DUAL。DUAL表在达梦中是存在的。手动执行验证用数据库客户端工具如达梦的管理工具直接用连接池配置的用户名密码登录手动执行一遍SELECT 1 FROM DUAL确保该用户有权限。调整检测策略如果网络不稳定可以尝试将test-on-borrow设为true牺牲一点性能确保每次取用的连接都是好的。但更推荐保持test-while-idletrue并适当缩短time-between-eviction-runs-millis。5.3 监控页面无法访问或空白问题现象能登录但监控页面数据不显示或者页面是空白的。排查步骤检查过滤器配置确认spring.datasource.druid.web-stat-filter.url-pattern配置正确通常为/*。同时检查exclusions是否不小心把/druid/*路径也排除了。检查StatViewServlet配置确认spring.datasource.druid.stat-view-servlet.enabledtrue且url-pattern/druid/*。查看浏览器控制台按F12打开开发者工具查看Console或Network标签页是否有JS或CSS资源加载失败。这可能是由于项目使用了某种严格的安全策略如CSP拦截了Druid内置的静态资源。可以尝试调整安全配置或者使用Druid提供的common.js、common.css等文件的CDN地址在官方文档中查找进行覆盖。权限问题确保当前登录的用户具有访问监控数据所需的权限。Druid监控后台的数据来源于StatFilter如果过滤器没正确工作数据就是空的。5.4 连接数缓慢增长直至耗尽问题现象这是典型的连接泄漏。应用运行一段时间后数据库连接数活跃空闲逐渐达到max-active新的请求开始等待或报错。排查与解决开启泄漏检测如3.2节所述立即配置remove-abandoned等相关参数并分析日志。检查代码重点审查所有操作数据库的地方是否使用了try-with-resourcesJava 7确保资源自动关闭或者在finally块中显式关闭了Connection、Statement、ResultSet。特别注意在循环体内创建连接或语句的情况。检查框架使用如果你使用了某些ORM框架的“懒加载”特性在事务范围外访问关联对象可能会触发新的查询而无意中占用连接。确保你的数据库操作都在明确的事务边界内。利用监控定位在Druid监控台的“连接持有时间分布”中找到那些持有时间超长的连接结合log-abandoned输出的堆栈信息精准定位到问题代码行。配置Druid连接池连接达梦8从技术上看并不复杂但魔鬼藏在细节里。一个validation-query的差异、一个max-active参数的不当设置都可能在特定场景下引发线上故障。我的经验是在开发测试阶段就充分压测观察监控提前将参数调整到一个合理的范围。上线后也要把Druid监控台作为日常巡检的一部分关注连接数、慢SQL等关键指标的变化趋势这样才能让这套组合真正稳定、高效地支撑你的业务。
