1. 项目概述为什么一个连接池要管多个库你有没有遇到过这种场景一个后台服务既要查用户中心的MySQL又要写订单日志到PostgreSQL还得定时从Oracle同步基础配置甚至偶尔调用SQL Server里的历史报表视图。这时候如果每个数据库都配一套独立的Druid连接池——四套配置、四套监控指标、四套健康检查逻辑光是YAML文件就容易看花眼更别说上线后排查“为什么订单日志写慢了但用户登录没影响”这种问题时得在四个监控面板之间反复切换。这就是“Druid连接池实现自定义场景的多数据库连接”的真实起点它不是为炫技而生的架构玩具而是面向中大型业务系统里数据源异构化、职责边界清晰化、运维可观测性统一化这三重现实压力所给出的务实解法。核心关键词是Druid、多数据库、自定义场景、连接池——注意这里说的“多数据库”不是指分库分表那种逻辑库而是物理上完全独立、协议不同、驱动各异、账号隔离的真实数据库实例而“自定义场景”恰恰是它区别于Spring Boot自动装配的要害比如某次大促前需要临时给订单库加专属连接池参数最小空闲数拉到20、超时时间缩到3秒但用户库保持默认策略又比如灰度发布时新版本服务只允许访问测试环境的PostgreSQL老版本仍走生产MySQL这种动态路由能力原生Druid根本不提供。我带过的几个项目里最典型的是某高校教务系统的微服务改造。它原本是单体Java应用数据库层混用MySQL主业务、SQL Server学籍档案、达梦国产化适配模块。迁移到Spring Cloud后团队第一反应是“每个服务配一个数据源”结果API网关一压测发现80%的线程卡在Druid的getConnection()阻塞队列里——不是数据库慢是三个数据源共用同一套连接池参数MySQL的慢查询把SQL Server的快速查询请求全堵死了。后来我们把连接池拆成三个独立实例再用一个轻量级路由层做统一封装问题当场解决。这件事让我意识到多数据源管理的本质从来不是“能不能连上”而是“如何让不同SLA要求的数据库在同一套连接池框架下互不干扰地呼吸”。所以这篇内容适合谁如果你正在做以下任何一件事它就值得你逐行读完正在将单体应用拆分为微服务且各服务依赖不同数据库需要支持国产数据库如达梦、人大金仓与MySQL共存的混合部署在做数据库中间件POC想验证Druid能否作为底层连接池支撑ShardingSphere或MyCat被DBA要求对不同库设置差异化的连接回收策略比如Oracle必须30分钟强制重连MySQL可设为2小时或者只是单纯被“dataSourceBean注入冲突”折磨过想搞懂Spring里Primary和Qualifier背后到底发生了什么。接下来的内容不会复述Druid官网那几页配置说明。我会带你从零开始亲手搭出一个能同时管理MySQL、PostgreSQL、H2用于本地测试的Druid连接池集群并重点拆解三个实战中最痛的环节如何让每个数据源拥有独立的监控埋点避免Prometheus抓到一堆混淆的druid_pool_active_count、如何在运行时动态切换数据源而不重启比如故障时自动降级到备用库、以及怎么用最少的代码侵入让MyBatis的SelectProvider方法自动识别当前该走哪个库。所有方案均经过生产环境验证参数值直接抄作业即可。2. 架构设计与选型逻辑为什么不用ShardingSphere或MyCat2.1 多数据源方案的三类技术路径在动手写代码前必须先厘清一个关键认知“多数据库连接”不等于“分布式数据库”。很多开发者一看到标题就本能想到ShardingSphere或MyCat这是典型的路径依赖。实际上针对“一个应用连多个异构库”这个需求业界存在三种截然不同的技术路径它们解决的问题域完全不同方案类型典型代表核心目标适用场景与本项目的匹配度代理层分流ShardingSphere-JDBC、MyCat将SQL解析后路由到不同物理库对应用透明分库分表、读写分离、同构数据库水平扩展❌ 不匹配。本项目要求连接MySQL/PostgreSQL等异构库且SQL语法差异大代理层无法安全路由JDBC驱动聚合Atomikos、BitronixXA事务管理器保证跨库事务的ACID通过两阶段提交协调强一致性要求场景如银行转账⚠️ 过度设计。本项目未提事务一致性需求引入XA会显著增加锁等待和性能损耗连接池实例化路由封装Druid多实例 自定义RoutingDataSource为每个库提供独立连接池由业务代码或AOP决定使用哪个混合数据库、国产化适配、差异化运维策略✅ 完全匹配。轻量、可控、无额外组件依赖提示选择Druid多实例方案的核心理由是它把“连接管理”和“SQL执行”彻底解耦。Druid只负责高效创建、复用、销毁物理连接而“该连哪个库”这个决策权交还给业务层——这正是“自定义场景”的题中之义。2.2 Druid为何是首选对比HikariCP与Tomcat JDBC既然确定走“多实例”路线为什么选Druid而不是更轻量的HikariCP这里有个常被忽略的硬性约束国产数据库兼容性。某次给某政务系统做国产化适配时我们试过HikariCP连接达梦数据库结果在高并发下频繁抛出java.sql.SQLException: Connection is not available, request timed out after 30000ms。排查发现是HikariCP的connection-test-query默认值SELECT 1不被达梦识别达梦要求SELECT 1 FROM DUAL而Druid的validationQuery支持按数据库类型自动适配且内置了达梦、人大金仓等国产库的专用检测逻辑。更关键的是监控维度。HikariCP的Metrics只有active、idle、pending三个基础指标而Druid提供了42个细粒度监控项包括poolingCount当前池中连接数notFullCount未达最大连接数的次数connectCount累计创建连接数closeCount累计关闭连接数executeCountSQL执行总次数errorCountSQL执行错误数这些指标对定位“多库混用”场景下的隐性问题至关重要。比如当PostgreSQL连接池的notFullCount持续为0但executeCount增长缓慢基本可以断定是网络层存在间歇性丢包因为连接池始终不敢扩容怕新建连接失败而MySQL池的errorCount突增但executeCount平稳则大概率是SQL语法错误或权限问题。这种诊断能力是HikariCP无法提供的。2.3 “自定义场景”的本质动态路由 vs 静态绑定很多教程教你怎么用AbstractRoutingDataSource实现多数据源但它们漏掉了一个致命细节静态配置的路由键lookupKey在Spring容器启动时就固化了无法响应运行时变化。比如某电商系统要求“大促期间所有订单查询强制走读库”如果路由逻辑写死在determineCurrentLookupKey()里就得改代码、发版、重启——这显然违背“自定义场景”的灵活性要求。我们的方案采用两级路由机制一级路由静态基于Spring Profile或配置中心开关决定启用哪些数据源如spring.profiles.activeprod,oracle-enabled二级路由动态通过ThreadLocal存储当前线程的DataSourceKey由AOP切面在DAO方法执行前注入支持注解驱动如TargetDataSource(order_postgres)或规则引擎如“当userId % 10 3时走测试库”。这种设计让“自定义场景”真正落地测试环境所有方法默认走H2内存库仅加TargetDataSource(mysql_prod)的才连生产库灰度环境通过Nacos配置target-datasource-strategyuserid-modulo动态分流故障应急运维人员在控制台输入set datasource fallback to mysql_backup5秒内生效。注意Druid本身不提供路由能力它只是被路由的目标。真正的“自定义”发生在路由层——这也是为什么本项目标题强调“Druid连接池实现...”而非“Druid实现...”。理解这一点才能避免后续踩坑。3. 核心实现与实操细节从配置到动态切换3.1 基础配置为每个数据库定制Druid连接池先看最基础的三库配置MySQL、PostgreSQL、H2。关键不是“怎么配”而是“为什么这样配”。以MySQL为例这是某金融系统生产环境的实际参数spring: datasource: mysql: url: jdbc:mysql://192.168.10.100:3306/user_center?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: user_rw password: ${MYSQL_PASSWORD} driver-class-name: com.mysql.cj.jdbc.Driver # Druid特有配置 druid: initial-size: 5 min-idle: 10 max-active: 50 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,log4j2 connection-properties: druid.stat.mergeSqltrue;druid.stat.slowSqlMillis5000参数选择逻辑详解initial-size: 5应用启动时预热5个连接避免首请求因建连延迟超时。实测某支付系统首请求耗时从1200ms降至210msmin-idle: 10保持10个空闲连接应对突发流量。设得太低如3会导致高峰期频繁创建/销毁连接CPU飙升设得太高如30则浪费数据库连接数Oracle默认上限仅200max-active: 50计算依据是QPS × 平均SQL耗时 × 2。假设订单库QPS为200平均SQL耗时100ms则理论需40个连接预留25%余量得50time-between-eviction-runs-millis: 60000每60秒扫描一次空闲连接。太短如10秒会增加Druid线程CPU占用太长如300秒导致失效连接清理不及时validation-query: SELECT 1MySQL用SELECT 1PostgreSQL必须用SELECT 1 AS a否则报错H2用SELECT 1 FROM INFORMATION_SCHEMA.SYSTEM_USERS。这是多库配置最容易出错的点——不同数据库的校验SQL必须严格区分。PostgreSQL配置的关键差异spring: datasource: postgres: url: jdbc:postgresql://192.168.10.101:5432/order_log?currentSchemapublicsslmodedisable username: log_writer password: ${PG_PASSWORD} driver-class-name: org.postgresql.Driver druid: # PostgreSQL专用参数 validation-query: SELECT 1 AS a # 关键PostgreSQL对连接泄漏更敏感需缩短空闲时间 min-evictable-idle-time-millis: 180000 # 3分钟比MySQL的5分钟更激进 # 启用PreparedStatement缓存PostgreSQL 9.2支持 pool-prepared-statements: trueH2内存库配置仅开发/测试用spring: datasource: h2: url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY-1;DB_CLOSE_ON_EXITFALSE username: sa password: driver-class-name: org.h2.Driver druid: # H2无需复杂连接管理 initial-size: 1 min-idle: 1 max-active: 20 # 关闭校验H2内存库极稳定 test-while-idle: false validation-query: 实操心得所有druid.*参数必须加在对应数据源的命名空间下如spring.datasource.mysql.druid.*而非全局spring.datasource.druid.*。否则Spring Boot会尝试用同一套参数初始化所有数据源导致PostgreSQL因validation-query不匹配而启动失败。3.2 多数据源Bean注册避免Primary冲突的终极解法Spring Boot 2.0默认只允许一个PrimaryDataSource Bean否则启动报错No qualifying bean of type javax.sql.DataSource。网上常见解法是“把主数据源标为Primary其他用Qualifier”但这会导致MyBatis的SqlSessionFactory只能注入主数据源其他库无法使用MyBatis。我们的解法是彻底放弃Spring Boot的自动配置手动注册所有DruidDataSource BeanConfiguration public class DataSourceConfig { Bean(mysqlDataSource) ConfigurationProperties(spring.datasource.mysql) public DruidDataSource mysqlDataSource() { return DruidDataSourceBuilder.create().build(); } Bean(postgresDataSource) ConfigurationProperties(spring.datasource.postgres) public DruidDataSource postgresDataSource() { return DruidDataSourceBuilder.create().build(); } Bean(h2DataSource) ConfigurationProperties(spring.datasource.h2) public DruidDataSource h2DataSource() { return DruidDataSourceBuilder.create().build(); } // 关键为每个数据源单独配置SqlSessionFactory Bean(mysqlSqlSessionFactory) public SqlSessionFactory mysqlSqlSessionFactory(Qualifier(mysqlDataSource) DataSource dataSource) throws Exception { SqlSessionFactoryBean factoryBean new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); factoryBean.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources(classpath:mapper/mysql/*.xml)); return factoryBean.getObject(); } Bean(postgresSqlSessionFactory) public SqlSessionFactory postgresSqlSessionFactory(Qualifier(postgresDataSource) DataSource dataSource) throws Exception { SqlSessionFactoryBean factoryBean new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); factoryBean.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources(classpath:mapper/postgres/*.xml)); return factoryBean.getObject(); } }这样做的好处每个SqlSessionFactory绑定唯一数据源Mapper XML文件按库分离mapper/mysql/UserMapper.xmlvsmapper/postgres/OrderLogMapper.xml业务代码中通过Autowired Qualifier(mysqlSqlSessionFactory)明确指定使用哪个完全规避Primary冲突且支持未来无缝接入更多数据库。注意ConfigurationProperties的prefix必须与YAML中的key完全一致包括大小写。曾有团队因写成ConfigurationProperties(spring.datasource.Mysql)M大写导致配置未生效排查3小时才发现是大小写问题。3.3 动态路由实现ThreadLocal AOP的黄金组合现在有了三个独立的Druid连接池下一步是让业务代码能“按需取用”。我们采用经典的AbstractRoutingDataSource但重写其determineCurrentLookupKey()方法使其从ThreadLocal读取动态键public class DynamicRoutingDataSource extends AbstractRoutingDataSource { private static final ThreadLocalString CONTEXT_HOLDER new ThreadLocal(); public static void setDataSourceKey(String key) { CONTEXT_HOLDER.set(key); } public static String getDataSourceKey() { return CONTEXT_HOLDER.get(); } public static void clearDataSourceKey() { CONTEXT_HOLDER.remove(); } Override protected Object determineCurrentLookupKey() { String key CONTEXT_HOLDER.get(); if (key null) { // 默认回退到mysql return mysql; } return key; } }然后配置这个动态路由数据源将其作为所有DAO操作的统一入口Bean Primary public DataSource routingDataSource() { DynamicRoutingDataSource routingDataSource new DynamicRoutingDataSource(); MapObject, Object targetDataSources new HashMap(); targetDataSources.put(mysql, mysqlDataSource()); targetDataSources.put(postgres, postgresDataSource()); targetDataSources.put(h2, h2DataSource()); routingDataSource.setTargetDataSources(targetDataSources); routingDataSource.setDefaultTargetDataSource(mysqlDataSource()); // 默认走MySQL return routingDataSource; }最后用AOP在DAO方法执行前注入路由键Aspect Component public class DataSourceAspect { Around(annotation(targetDataSource)) public Object routeToDataSource(ProceedingJoinPoint joinPoint, TargetDataSource targetDataSource) throws Throwable { String key targetDataSource.value(); DynamicRoutingDataSource.setDataSourceKey(key); try { return joinPoint.proceed(); } finally { DynamicRoutingDataSource.clearDataSourceKey(); // 必须清理避免线程复用污染 } } }业务代码中只需加注解Repository public class OrderLogDao { Autowired private SqlSessionTemplate sqlSessionTemplate; // 使用routingDataSource创建的模板 TargetDataSource(postgres) public void insertOrderLog(OrderLog log) { sqlSessionTemplate.insert(OrderLogMapper.insert, log); } }实操心得DynamicRoutingDataSource.clearDataSourceKey()必须放在finally块中。我们曾在线上遇到诡异问题——某个HTTP请求因异常未清理ThreadLocal导致后续复用该线程的请求全部路由到错误的库。加入finally后问题消失。3.4 监控埋点为每个数据源生成独立Prometheus指标Druid内置的DruidStatManagerFacade默认将所有数据源的指标汇总到同一组Metric这在多库场景下毫无意义。我们需要为每个DruidDataSource单独暴露指标。首先禁用Druid的自动监控spring: datasource: druid: web-stat-filter: false stat-view-servlet: false然后为每个数据源手动注册DruidStatManagerFacadeBean public ServletWebServerFactory servletContainer() { TomcatServletWebServerFactory tomcat new TomcatServletWebServerFactory(); // 为MySQL注册监控端点 tomcat.addAdditionalTomcatConnectors(createDruidStatConnector(mysql, /druid/mysql)); // 为PostgreSQL注册监控端点 tomcat.addAdditionalTomcatConnectors(createDruidStatConnector(postgres, /druid/postgres)); return tomcat; } private Connector createDruidStatConnector(String dataSourceName, String path) { Connector connector new Connector(org.apache.coyote.http11.Http11NioProtocol); connector.setScheme(http); connector.setPort(8080); connector.setSecure(false); connector.setRedirectPort(8443); // 关键为每个数据源创建独立的StatFilter StatFilter statFilter new StatFilter(); statFilter.setDbType(mysql); // 根据数据源类型设置 // 注册到Druid的统计管理器 DruidStatManagerFacade.getInstance().addStatFilter(statFilter, dataSourceName); return connector; }最终效果访问http://localhost:8080/druid/mysql看到MySQL池的实时指标http://localhost:8080/druid/postgres看到PostgreSQL池的指标完全隔离。提示Druid的StatFilter必须在DruidDataSource初始化后注册否则指标为空。因此addStatFilter()不能放在Bean方法里而要在ServletWebServerFactory中延迟执行。4. 常见问题与避坑指南那些文档里不会写的真相4.1 连接泄漏90%的“连接池打满”都是假象现象应用运行几天后Druid监控显示ActiveCount50已达max-active但PoolingCount却只有10WaitThreadCount飙升到200所有请求超时。排查过程首先确认是否真泄漏——执行show processlistMySQL或select * from pg_stat_activityPostgreSQL发现大量Sleep状态连接检查Druid日志搜索abandon关键字发现大量discard long time none received connection最终定位到某段代码// 错误示范未关闭ResultSet public ListUser findUsers() { Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(SELECT * FROM user); ResultSet rs ps.executeQuery(); // rs未关闭 return parse(rs); // 解析后rs被GC但Druid不知道 }根本原因Druid的连接回收依赖Connection.close()而ResultSet和PreparedStatement的关闭不是强制的。当ResultSet未关闭时Druid认为该连接仍在使用拒绝回收。解决方案强制规范所有DAO方法必须用try-with-resourcesDruid兜底在druid配置中开启remove-abandoned-on-borrow: true和remove-abandoned-timeout-millis: 60000自动回收超60秒未归还的连接监控告警在Prometheus中设置告警规则druid_pool_active_count{jobmyapp} / druid_pool_max_active{jobmyapp} 0.8。实操心得我们给所有团队立下铁律——任何手动获取Connection的代码必须经过三人Code Review。这条规矩实施后连接泄漏问题下降92%。4.2 数据库驱动冲突mysql-connector-java 8.x的隐藏陷阱现象应用启动时报错java.lang.NoClassDefFoundError: com/mysql/cj/jdbc/Driver但明明pom.xml里已声明依赖。根因Druid 1.2.8默认使用com.mysql.cj.jdbc.Driver而某些老项目仍用com.mysql.jdbc.Driver5.x驱动。更隐蔽的是Spring Boot 2.3的spring-boot-starter-jdbc会自动引入mysql-connector-java8.x但若项目中又显式引入了5.x版本Maven依赖树会出现冲突导致类加载失败。验证方法mvn dependency:tree | grep mysql若输出中同时出现mysql:mysql-connector-java:5.1.49和mysql:mysql-connector-java:8.0.33即存在冲突。解决步骤在pom.xml中排除旧版本dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId exclusions exclusion groupIdmysql/groupId artifactIdmysql-connector-java/artifactId /exclusion /exclusions /dependency显式声明8.x驱动dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency更新Druid配置中的driver-class-name为com.mysql.cj.jdbc.Driver。注意MySQL 8.x驱动要求URL中必须包含serverTimezone参数否则报错The server time zone value XXX is unrecognized。这是新手最常踩的坑。4.3 国产数据库适配达梦的三个致命参数某政务项目对接达梦数据库时出现两个诡异问题问题1连接池初始化成功但首次查询报错java.sql.SQLException: socket creation error问题2高并发下连接池频繁重建CreateCount指标每分钟增长50。排查发现达梦官方文档要求三个关键参数必须显式设置spring: datasource: dameng: url: jdbc:dm://192.168.10.102:5236?socketTimeout30000loginTimeout10000zeroDateTimeBehaviorconvertToNull username: sysdba password: ${DM_PASSWORD} driver-class-name: dm.jdbc.driver.DmDriver druid: # 达梦专用 validation-query: SELECT 1 FROM DUAL # 关键达梦的连接检测必须用DUAL表 test-while-idle: true # 达梦对空闲连接更敏感需缩短检测间隔 time-between-eviction-runs-millis: 30000 # 必须关闭PreparedStatement缓存达梦不支持 pool-prepared-statements: false其中socketTimeout30000解决第一个问题网络超时pool-prepared-statements: false解决第二个问题达梦的PreparedStatement缓存机制与Druid冲突。实操心得对接任何国产数据库第一件事不是写SQL而是去官网找《JDBC编程指南》把“连接参数”“校验SQL”“驱动类名”三个字段抄下来贴在工位上。我们团队为此制作了《国产数据库JDBC速查表》覆盖达梦、人大金仓、神舟通用、南大通用四大厂商已内部使用三年零失误。4.4 Spring事务失效Transactional为何不生效现象在一个Service方法中先调用mysqlDao.updateUser()再调用postgresDao.insertLog()加了Transactional注解但MySQL更新成功、PostgreSQL插入失败时MySQL的更新未回滚。原因Transactional默认只作用于单个DataSource。当方法内调用多个数据源时Spring的事务管理器PlatformTransactionManager只能管理其中一个。解决方案有二简单场景非强一致性放弃跨库事务用“本地事务消息队列”最终一致性。例如MySQL更新后发MQ消息由独立消费者处理PostgreSQL日志写入强一致性场景引入Atomikos配置JTA事务管理器Bean(name jtaTransactionManager) public JtaTransactionManager transactionManager() { JtaTransactionManager manager new JtaTransactionManager(); manager.setTransactionManager(transactionManager()); manager.setUserTransaction(userTransaction()); return manager; }但代价是性能下降30%-50%且配置复杂。我的建议95%的业务场景都不需要跨库事务。与其花两周调试Atomikos不如重构业务逻辑——把“用户更新”和“日志写入”拆成两个独立API用Saga模式协调。某电商系统实践表明这种重构反而提升了系统可用性。5. 生产级增强从能用到好用的五个关键升级5.1 连接池参数动态化配置中心驱动的实时调优Druid的参数在应用启动后即固化但生产环境常需动态调整。比如大促前要把MySQL池的max-active从50提到100传统做法是改配置、重启——这不可接受。我们基于Nacos实现参数热更新Component RefreshScope public class DruidConfigRefresher { Autowired private DruidDataSource mysqlDataSource; Value(${druid.mysql.max-active:50}) private int maxActive; EventListener public void onConfigChange(RefreshEvent event) { if (event.getScope().contains(druid)) { mysqlDataSource.setMaxActive(maxActive); log.info(Druid maxActive updated to {}, maxActive); } } }配合Nacos配置druid.mysql.max-active100 druid.postgres.min-idle15注意不是所有Druid参数都支持运行时修改。initial-size、driver-class-name等初始化参数修改无效必须重启。可动态修改的参数列表见Druid官方文档DruidDataSource类的setXxx()方法。5.2 故障自动降级当PostgreSQL宕机时无缝切到MySQL备份库核心逻辑定期探测各数据源健康状态当连续3次探测失败自动将路由键映射到备用库。Component public class DataSourceHealthChecker { Autowired private DruidDataSource postgresDataSource; Autowired private DruidDataSource mysqlBackupDataSource; private final MapString, AtomicInteger failureCount new ConcurrentHashMap(); Scheduled(fixedRate 30000) // 每30秒检测 public void checkPostgresHealth() { try { Connection conn postgresDataSource.getConnection(); conn.close(); failureCount.computeIfPresent(postgres, (k, v) - { v.set(0); return v; }); } catch (Exception e) { AtomicInteger count failureCount.computeIfAbsent(postgres, k - new AtomicInteger(0)); if (count.incrementAndGet() 3) { // 触发降级 DynamicRoutingDataSource.setFallback(postgres, mysql_backup); log.warn(PostgreSQL health check failed 3 times, fallback to mysql_backup); } } } }实操心得降级逻辑必须幂等。我们曾因未加锁导致多次触发降级造成MySQL备份库被打爆。现改为AtomicInteger计数ConcurrentHashMap存储确保线程安全。5.3 SQL审计增强精准定位慢查询归属库Druid的stat过滤器默认将所有SQL汇总无法区分是MySQL还是PostgreSQL的慢查询。我们通过FilterChainImpl注入库标识public class DatabaseTypeFilter extends FilterAdapter { Override public void statementExecuteBefore(FilterChain chain, StatementProxy statement, String sql) throws SQLException { String dbType statement.getConnectionProxy().getDirectDataSource().getDbType(); MDC.put(db_type, dbType); // 写入日志上下文 super.statementExecuteBefore(chain, statement, sql); } }配合Logback配置appender nameSQL_LOG classch.qos.logback.core.rolling.RollingFileAppender filelogs/sql.log/file encoder pattern%d{HH:mm:ss.SSS} [%thread] [%X{db_type}] %-5level %logger{36} - %msg%n/pattern /encoder /appender日志中每条SQL前都会标注[mysql]或[postgres]排查问题时一目了然。5.4 连接池优雅停机K8s滚动更新不丢连接K8s滚动更新时旧Pod收到SIGTERM信号后应等待所有连接归还Druid池再退出。否则正在执行的SQL会被中断引发数据不一致。Component public class GracefulShutdown implements DisposableBean { Autowired private DruidDataSource mysqlDataSource; Autowired private DruidDataSource postgresDataSource; Override public void destroy() throws Exception { log.info(Starting graceful shutdown...); // 等待所有连接归还最多30秒 mysqlDataSource.close(); postgresDataSource.close(); log.info(All data sources closed); } }K8s Deployment中配置livenessProbe: httpGet: path: /actuator/health port: 8080 readinessProbe: httpGet: path: /actuator/health port: 8080 terminationGracePeriodSeconds: 60 # 给足关闭时间5.5 容器化部署优化JVM参数与Druid的协同在Docker中运行时常因JVM堆内存设置不当导致Druid OOM。关键原则Druid的连接池内存占用 ≈ max-active × 单连接内存约2MB。例如MySQL池max-active50则需预留100MB堆内存给连接池。若JVM堆设为512MB实际可用内存仅剩412MB极易OOM。推荐配置# Dockerfile FROM openjdk:11-jre-slim ENV JAVA_OPTS-Xms512m -Xmx1024m -XX:MaxMetaspaceSize256m -XX:UseG1GC CMD java $JAVA_OPTS -jar app.jar并设置Druid参数druid: max-active: 30 # 根据JVM堆大小反推 pool-prepared-statements: true max-pool-prepared-statement-per-connection-size: 10最后分享一个小技巧在K8s中用kubectl exec -it pod -- jmap -histo:live pid查看堆中DruidPooledConnection实例数若远超max-active说明存在连接泄漏立即排查。我在实际使用中发现把Druid连接池当成“黑盒”来用是最危险的。它不像HikariCP那样追求极致轻量而是以“企业级可观测性”为核心设计哲学。每一个参数背后都对应着数据库的某种物理限制如
