Druid连接池为什么比Hikari更适配Oracle监控需求
说到监控Oracle数据库的连接池，很多开发者可能会发现，事情没那么简单。Oracle的官方JDBC驱动在暴露连接状态、会话级指标（比如SQL执行耗时、等待事件）方面，远不如MySQL那样“友好”。这时候，连接池的选择就变得至关重要了。
核心差异在于，Druid内置了专门的OracleDataSource适配器。这个适配器能主动去解析Oracle的系统视图，比如V$SESSION和V$SQLAREA，从而拿到深度的运行时数据。反观HikariCP，它完全依赖于标准的JDBC接口，对于Oracle的这些特有指标，可以说是“束手无策”。换句话说，如果监控只停留在查看activeCount（活跃连接数）或waitCount（等待数）这种通用层面，那对于Oracle数据库而言，基本等于没有进行有效监控。
具体来看，Druid的适配优势体现在几个关键细节上：
- 它默认会将
connectTimeout和socketTimeout等参数透传到Oracle JDBC驱动层，有效避免因网络或长事务导致的连接卡死。 - 对于Oracle数据库典型的
ORA-00060死锁错误，Druid能够识别并自动记录相关的堆栈信息。而HikariCP通常只会抛出一个不带上下文的通用SQLException，排查起来如同大海捞针。 - 通过开启
StatFilter的logSlowSql选项，Druid可以捕获SQL执行时的真实绑定变量值。这一点尤其重要，因为Oracle原生驱动默认不会记录这些参数，使得慢SQL分析往往缺失关键信息。
application.yml里必须显式配置的5个Druid参数
在Spring Boot项目中集成Druid时，千万别以为把spring.datasource.type改成com.alibaba.druid.pool.DruidDataSource就万事大吉了。Spring Boot的自动装配机制下，很多关键的监控功能默认是关闭的，需要手动开启。
下面这五个配置项，漏掉任何一个都可能让监控面板形同虚设：
druid.stat-view-servlet.enabled: true— 这是启用Druid内置监控页面的开关。不打开，访问/druid路径只会得到404。druid.web-stat-filter.enabled: true— 必须启用Web关联监控的Filter。否则，SQL监控列表里将永远没有数据。druid.filter.stat.log-slow-sql: true— 开启慢SQL记录。注意，Oracle场景下的默认慢SQL阈值是3秒，对于性能要求高的系统，这个值可能偏大。druid.filter.stat.slow-sql-millis: 1000— 因此，建议将慢SQL阈值明确调整为1000毫秒（或其他适合的值）。这个配置必须和上一项同时存在才生效。druid.filter.config.decrypt: false— 如果数据库密码使用了加密，但未配置对应的解密公钥，务必将此选项设为false，否则应用启动就会失败。
可以这么说，如果这些配置没配齐，那么通过DruidStatManagerFacade.getInstance().getDataSourceStatDataList()这个API获取到的监控数据，很可能就是一个空集合。
Oracle-specific监控项怎么在Druid里取到
Druid对Oracle的深度支持，体现在一个专门的oracleStat属性上。这些Oracle特有的监控指标，都封装在DruidDataSourceStatValue对象的这个属性下，但并非所有Druid版本都默认暴露。通常需要Spring Boot 2.7及以上版本配合Druid 1.2.16+才能获得完整支持。
如何获取这些宝贵的数据呢？看下面几个例子：
- 当前活跃会话数：
stat.getOracleStat().getActiveSessionCount() - 最近1分钟硬解析次数：
stat.getOracleStat().getHardParseCountPerSecond()（注意是每秒计数，需结合时间窗口计算） - PGA内存使用峰值：
stat.getOracleStat().getPgaMemoryMax()
这里有个关键点：要拿到这些值，必须首先从数据源对象调用DruidDataSource.getOracleStat()方法。不能试图直接从StatFilter的回调方法里读取，那样是拿不到的。
另外，如果遇到getOracleStat()返回null的情况，首先要怀疑Druid是否正确识别了Oracle驱动。请检查spring.datasource.driver-class-name，务必设置为oracle.jdbc.OracleDriver。这里有个历史坑点：不要使用已废弃的oracle.jdbc.driver.OracleDriver。
Druid + Oracle在高并发下容易触发的3个坑
在Oracle RAC环境或那些启用了DBMS_APPLICATION_INFO等高级特性的系统中，Druid的某些默认行为可能会引发意想不到的问题，比如连接泄漏或监控数据失真。
下面这三个场景，尤其需要警惕：
- 超时参数未传递：如果没有在Druid配置中通过
druid.connection-properties显式设置Oracle驱动的网络超时参数（如oracle.net.CONNECT_TIMEOUT=5000;oracle.jdbc.ReadTimeout=30000），在高并发或网络不稳时，连接池线程可能卡在SocketInputStream.read上。这会导致监控中的ActiveCount虚高，但实际上连接已被“卡住”。 - SQL合并功能干扰Oracle提示：当开启
druid.filter.stat.merge-sql: true（用于合并相同SQL以方便统计）时，Oracle SQL中的优化器提示（如/*+ USE_NL(t1,t2) */）可能会被合并掉。这会导致原本不同的慢SQL被错误地归为一类，影响性能分析的准确性。 - 连接回收机制误杀：Druid的
RemoveAbandonedOnMaintenance功能（用于清理疑似泄露的连接）在Oracle中可能“误伤”。如果一个连接正在执行一个长时间运行的PL/SQL块，虽然它实际上在工作，但可能被检测机制误判为“已泄露”而强制关闭。在Oracle环境下，建议关闭此功能：druid.remove-abandoned-on-maintenance: false。
最后，还有一个比较隐蔽的版本适配问题：从Oracle 19c开始，默认启用了ENABLE_BROKEN连接检测机制。如果此时Druid的validationQuery（连接有效性检测SQL）仍然使用经典的SELECT 1 FROM DUAL，可能会意外触发Oracle内部的连接重试逻辑，反而增加验证延迟。更稳妥的做法是将其替换为SELECT SYSDATE FROM DUAL。
