为什么必须用 ojdbc8，而不是 ojdbc6 或 ojdbc10
这事儿其实挺关键的。Oracle 19c 官方白纸黑字要求 JDK 8 及以上版本，而 ojdbc8 是唯一一个能同时满足两个条件的“天选之子”：既要支持 Oracle 19c 的那些新特性（比如 Application Continuity、分片元数据），又得完美兼容 JDK 8 到 11 这个主流版本区间。
选错了会怎样？用 ojdbc6 的话，你会直接撞上 ja va.lang.NoSuchMethodError，告诉你某个方法找不到了；而如果用 ojdbc10 在 JDK 8 环境下跑，那更干脆，直接就是一个 ClassFormatError——因为它编译时用的字节码版本就是瞄着 JDK 10+ 去的，JDK 8 根本不认识。
所以，实操上就这么干：
- 直接从 Oracle 官网下载
ojdbc8-19.21.0.0.jar（注意区分，别下成那个带调试符号、体积庞大的ojdbc8-full.jar，生产环境用不着）。 - 如果是 Ma ven 项目，直接用中央仓库的这个坐标：
com.oracle.database.jdbc:ojdbc8:19.21.0.0。好消息是，Oracle 现在已经把它同步到 Ma ven Central 了，不用再费劲配私有仓库。 - 如果你在用 Spring Boot 2.5+，要留个心眼：
spring-boot-starter-jdbc默认是不带 Oracle 驱动的。你必须显式声明依赖，否则启动时就会给你来个下马威：Failed to determine embedded database driver class。
oracle.jdbc.driver.OracleDriver 已废弃，该用哪个类名
这是一个经典的“历史遗留问题”。从 ojdbc6 开始，老牌的 oracle.jdbc.driver.OracleDriver 就被打上了 @Deprecated 标签。到了 ojdbc8 时代，虽然这个类还能凑合用，但控制台会不断给你打印警告日志。Oracle 19c 的官方文档说得明明白白：推荐使用 oracle.jdbc.OracleDriver（注意看，包路径里少了一个 driver）。Spring Boot 2.3+ 的 JdbcDataSourceBuilder 也默认会尝试加载这个新的类名。
具体操作上，记住这几点：
- 如果你需要手动注册驱动，代码请写成
Class.forName("oracle.jdbc.OracleDriver")，别再抄那些老旧教程里的包名了。 - 如果项目用的是 HikariCP 连接池，那么
driver-class-name这个配置项必须设为oracle.jdbc.OracleDriver，否则连接池初始化就会失败，并报错Unable to load class: oracle.jdbc.driver.OracleDriver。 - 即使在 Tomcat 的
context.xmlfactory="org.apache.tomcat.jdbc.pool.DataSourceFactory"，驱动类的选择逻辑不变，driverClassName同样得填新的类名。
URL 格式里要不要加 ?useSSL=false 这类 MySQL 风格参数
千万别！这是一个常见的思维定式错误。Oracle JDBC 的 URL 格式里根本没有 useSSL 这个参数。你硬加上去，只会导致 URL 解析失败，抛出 ja va.sql.SQLException: Invalid connection string format。Oracle 对 SSL/TLS 的控制是依靠独立的属性来实现的，比如 oracle.net.ssl_server_dn_match=true，而且通常只在启用了 Wallet 或配置了 TLS 加密时才需要关心这些。
那么，正确的 URL 应该怎么写？看这里：
- 标准格式：
jdbc:oracle:thin:@//host:port/service_name（这是目前最推荐的方式）。或者，如果你还在用传统的 SID 模式（注意，19c 默认用的是 service_name），格式是：jdbc:oracle:thin:@host:port:SID。 - 连接 RAC 或使用 SCAN 地址时：URL 就得复杂点了，得写成类似
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scan-host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=myservice)))这种 TNS 风格，不能简单地拼接 host 和 port。 - 还有一个实战小技巧：如果应用部署在容器环境里，并且遇到 DNS 解析慢的问题，可以在连接属性里加上
oracle.net.disableOscar=true。这能跳过 Oracle 客户端的自动服务注册探测，避免不必要的连接超时。
连接池里 validationQuery 设成 SELECT 1 FROM DUAL 会出问题吗
直接说结论：不会导致功能错误，但效率上不是最优解。虽然 Oracle 的 DUAL 表是个只有一行的虚拟表，但每次执行这个校验查询，都会触发一次完整的 SQL 解析和执行计划生成，开销其实不小。更优雅的做法是利用驱动本身提供的轻量级检测机制——ojdbc8 支持底层的 oracle.jdbc.thinOracleDriver.pingDatabase 调用。对应到连接池配置上，就是 HikariCP 的 connection-test-query 或者 Druid 的 validationQuery 参数，但它们的值应该考虑比 SELECT 1 FROM DUAL 更高效的方式。
具体到不同的连接池，可以这样优化：
- 对于 HikariCP：推荐的做法是直接关闭
connection-test-query，转而设置connection-init-sql=ALTER SESSION SET CURRENT_SCHEMA=YOUR_SCHEMA（这样连接初始化时还能顺便切换一下 schema），然后再配合设置keepalive-time=30000让连接池自己维护连接活性。 - 对于 Druid：目前还是需要设置
validationQuery=SELECT 1 FROM DUAL。但关键是要把检测策略从testOnBorrow（借出时检测）改为testWhileIdle（空闲时检测），同时调大timeBetweenEvictionRunsMillis（比如设为 60000 毫秒），以此来大幅降低检测频率。 - 通用重要设置：无论你用哪种连接池，都强烈建议开启
oracle.jdbc.useFetchSizeWithLongColumn=true这个属性（可以加在 URL 末尾，或者数据源属性里）。它能有效防止处理 CLOB/BLOB 这类大字段时可能发生的内存溢出问题。
最后再叮嘱一句：Oracle 19c 在 TNS 连接字符串解析、Wallet 加载、连接存活检测这些环节，配置参数非常“娇贵”，稍有错位就可能静默失败，或者延迟好几秒才报错。配置完成后，务必先用 telnet host 1521 和 tnsping SERVICE_NAME 这两个命令，验证一下网络连通性和监听服务是否正常，把问题扼杀在摇篮里。
