根因是统计信息未更新或配置不当：19c优化器更依赖准确统计信息，迁移后若未执行dbms_stats.gather_schema_stats，旧统计信息会导致执行计划异常；需用estimate_percent=>10替代auto_sample_size，直方图加size 254，并行级联收集确保索引与表统计同步。
不是java程序本身变慢，而是它发出的sql在19c上执行计划走歪了——最常见、最隐蔽的根因是统计信息没重收集，其次是jdbc驱动不匹配。
DBA没重收集统计信息，19c优化器直接“瞎猜”
19c的CBO比11g更依赖准确的统计信息，尤其对直方图和列分布敏感。迁移后若只用expdp/impdp导入数据，DBMS_STATS.GATHER_SCHEMA_STATS没强制跑一遍，旧统计信息（可能来自11g时代）会留在19c里。
- 查表是否陈旧：
SELECT owner, table_name, last_analyzed FROM dba_tables WHERE owner = 'PROD' AND last_analyzed - 查关键字段缺直方图：
SELECT column_name, histogram FROM dba_tab_col_statistics WHERE table_name = 'ORDER_HEADER' AND histogram = 'NONE' - 对比执行计划：在19c中
EXPLAIN PLAN FOR慢SQL，再SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)，看是否从INDEX RANGE SCAN退化成TABLE ACCESS FULL
JDBC驱动版本错配，导致绑定变量失效
升级19c后，若应用仍用11g的ojdbc6.jar或ojdbc7.jar，驱动无法正确传递绑定变量特征给19c优化器，触发“绑定变量窥探失效”，进而生成次优计划。现象是：PL/SQL里手动执行快（硬编码值），Java里参数化执行极慢。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 确认驱动版本：
SELECT * FROM v$version查数据库版本，再核对应用CLASSPATH里的jar包名（如ojdbc8.jar对应Java 8+、19c兼容） - 临时验证法：在SQL里加提示
/*+ OPTIMIZER_FEATURES_ENABLE('11.2.0.4') */，如果变快，基本锁定是驱动/优化器适配问题 - 别混用：JDK 8必须配
ojdbc8.jar（class file version 52.0），JDK 11+才可用ojdbc11.jar（54.0+）
直方图精度不足，状态码类字段全军覆没
业务表里像order_status这种只有'P','S','C'几个值的字段，在11g里用FOR ALL COLUMNS SIZE AUTO可能侥幸够用；但19c的AUTO默认建直方图更保守，极易漏掉，导致优化器误判选择性，放弃索引。
- 别信
SIZE AUTO：对这类低基数字段，显式指定method_opt => 'FOR COLUMNS order_status SIZE 254' - 大表慎用
AUTO_SAMPLE_SIZE：19c采样逻辑更激进，超大表上易低估高频值密度，改用estimate_percent => 10更稳 - 级联收集必须带并行：
cascade => TRUE, degree => 4，否则索引统计滞后于表统计，优化器看到“表小索引大”，直接弃用索引
真正卡住人的地方，往往不是“该不该重收集统计信息”，而是“重收集时参数怎么配”。一个SAMPLE_SIZE设错，或漏掉一个SIZE 254，就足以让核心报表查询从秒级拖到小时级——而日志里只报“超时”，根本看不出是统计信息在捣鬼。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
