java应用迁移后sql执行计划变差，主因是jdbc连接参数、驱动版本升级或绑定变量行为变化（如类型推断、空格值）触发了oracle优化器的决策偏差，而非jdbc主动刷新计划；应通过固化sql plan baseline并控制硬解析时机来恢复。
java 应用迁移后 sql 执行计划变差，通常不是 jdbc 本身“导致”的，而是 jdbc 的行为（比如绑定变量使用方式、连接参数、驱动版本）放大了 oracle 优化器在新环境下的决策偏差。你无法通过 jdbc “强制刷新执行计划”，但可以控制触发硬解析的时机和条件——而这恰恰是让好计划重新加载的关键入口。
Java 应用没改 SQL，为什么 plan_hash_value 突然变了？
常见错误现象：v$sql 里同一条 sql_id 对应多个 plan_hash_value，且新计划性能明显下降；dba_hist_sqlstat 显示迁移前后 elapsed_time_total / executions_total 翻倍甚至更高。
根本原因不是 JDBC 主动“刷新”了什么，而是以下任一情况在迁移后被触发：
- JDBC 连接串新增或修改了
useServerPrepStmts=true或cachePrepStmts=true，导致 PreparedStatement 缓存行为变化，间接影响游标共享和计划复用 - Oracle 驱动从 ojdbc6 升级到 ojdbc8，后者默认启用
oracle.jdbc.autoCommitSpecCompliant=false和更激进的绑定变量类型推断（如把String绑定为VARCHAR2(32767)），引发隐式类型转换，破坏索引访问路径 - 应用重启后首次执行 SQL 时传入的绑定变量值恰好触发了 bind peeking + 直方图组合陷阱（比如第一次查的是高频值，生成全表扫描计划，后续低频值也沿用）
- 迁移后未同步
optimizer_features_enable或_optim_peek_user_binds等隐含参数，导致优化器行为偏移
jdbc:oracle:thin 连接串里哪些参数会悄悄影响执行计划
这些配置不报错，但会让同一段 Java 代码在新库跑出完全不同计划：
-
SetBigStringTryClob=true：强制把长字符串绑定为CLOB，若字段是VARCHAR2，会触发隐式转换，索引失效 → 出现FULL TABLE SCAN -
remarksReporting=true：某些旧版驱动开启后会额外发送元数据查询，干扰共享池中父游标稳定性 -
implicitCachingEnabled=true且statementCacheSize设置过大：缓存了已失效的执行计划，重用时直接走坏计划 - 遗漏
oracle.jdbc.J2EE13Compliant=true：在 WebLogic 等容器中，不设此参数可能导致驱动忽略应用服务器传递的事务隔离级别，间接影响优化器对并发访问的判断
验证方法：抓取迁移前后两次相同 Java 请求的 v$session + v$sql_plan 关联结果，对比 child_number 和 plan_hash_value，再查 v$sql_bind_capture 看绑定变量实际类型是否一致。
想让 JDBC 触发一次硬解析来加载基线计划，该怎么做
这不是“刷新”，而是**制造可控的硬解析机会**，让优化器有机会捡起你提前准备好的 SQL Plan Baseline。
- 确保目标 SQL 已有
enabled=TRUE且accepted=TRUE的基线（查dba_sql_plan_baselines） - 在 Java 中执行前，显式调用
connection.createStatement().execute("ALTER SYSTEM FLUSH SHARED_POOL")—— 不推荐生产用，仅限紧急恢复 - 更安全做法：在关键 SQL 执行前加一句
/*+ OPT_PARAM('_optimizer_use_feedback' 'false') */提示，避免自适应计划干扰基线选择 - 终极兜底：用
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE把当前缓存里的好计划固化成基线，再让 JDBC 应用自然触发硬解析（比如改个无害注释：SELECT /*+ MIGRATION_FIX_202605 */ * FROM ...）
注意：LOAD_PLANS_FROM_CURSOR_CACHE 只能加载仍在 v$sql 里的计划；如果计划已老化，必须先用 DBMS_SQLTUNE.CREATE_SQLSET 从 AWR 抽出来，再导入。
绑定变量值分布不均时，Java 层最该检查什么
这是迁移后最隐蔽的性能雷区：SQL 文本和字段定义完全一样，但因 Java 传参习惯不同，让 bind peeking 锁死坏计划。
- 检查是否所有 DAO 方法都统一用了
setString()而非setObject(idx, val, Types.VARCHAR)—— 后者在 ojdbc8 下可能触发更宽泛的字符集推断 - 确认日志中绑定值是否带空格或不可见字符（如
" 123 "），这类值在直方图统计中属于“稀有值”，但被 peek 到后生成的计划却用于处理“主流值” - 避免在循环中反复
prepareStatement(sql).setXxx(...).executeQuery()：每次 prepare 都可能独立 peek，尤其当循环内绑定值跨度极大时（如从'A'到'ZZZ'） - 对关键查询，改用
execute(String sql, Object[] params)形式（如 Spring JdbcTemplate），它内部会做类型缓存，比裸写 PreparedStatement 更稳定
真正难处理的从来不是“怎么固定计划”，而是“为什么同一个 Java 方法，在老库走索引，新库就全表扫”——答案往往藏在绑定变量的实际传输类型和第一次 peek 的那个值里，而不是 SQL 文本本身。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
