optimizer_features_enable 是关键开关，因oracle 11g默认启用新优化器行为（如严格类型隐式转换、谓词推入变更），导致旧sql执行计划变化而返回空结果；设为'10.2.0.2'可回退至10g规则。
为什么 optimizer_features_enable 是关键开关
oracle 11g 默认启用新优化器行为（如更严格的类型隐式转换、谓词推入策略变更），这会导致旧版应用中看似合法的 sql（比如 where a.c = '0'）在某些数据分布下返回空结果——不是语法错，而是执行计划变了。根本原因不是权限，而是优化器“理解”字段的方式不同了。把 optimizer_features_enable 设为 '10.2.0.2' 就是告诉 oracle：“按 10g 的规则解析和生成执行计划”，绕过 11g 引入的破坏性变更。
optimizer_features_enable 的两种设置方式及适用场景
会话级设置适合临时验证或开发调试；系统级设置才真正影响所有连接（包括应用服务器 JDBC 连接池里的连接）：
- 会话级：执行
ALTER SESSION SET optimizer_features_enable = '10.2.0.2';，仅对当前 SQL*Plus 或 PL/SQL Developer 会话生效 - 系统级：执行
ALTER SYSTEM SET optimizer_features_enable = '10.2.0.2' SCOPE=spfile;，需重启数据库才生效，且影响全局 - 若应用使用连接池（如 Tomcat 的 DBCP），只设会话级没用——连接从池里取出时已初始化完毕，必须用系统级
容易被忽略的副作用与验证要点
降级优化器版本不是万能解药，它会同步关闭 11g 新增的优化特性（如自适应游标共享、物化视图重写增强），可能让部分新写 SQL 变慢：
- 执行
SELECT * FROM v$parameter WHERE name = 'optimizer_features_enable';确认值已写入 SPFILE，而非仅 MEMORY - 重启后检查
v$sql中相同 SQL 的PLAN_HASH_VALUE是否变化，确认执行计划确实回退 - 不要设成
'9.2.0.8'或更低——11g 内部结构不支持太老的兼容模式，会报 ORA-02062 错误 - 如果应用同时依赖 11g 特有功能（如
LISTAGG），降级后这些函数仍可用，但其底层执行路径可能变保守
替代方案：比全局降级更精准的控制
真要兼顾新旧逻辑，优先考虑 SQL 层面干预，避免一刀切改系统参数：
- 对问题 SQL 加 Hint：
/*+ OPTIMIZER_FEATURES_ENABLE('10.2.0.2') */ SELECT ...，只影响该语句 - 用 SQL Profile 绑定旧执行计划：
DBMS_SQLTUNE.IMPORT_SQL_PROFILE，无需改参数也不影响其他 SQL - 检查是否真需要降级——有时只是缺少统计信息或列上有直方图导致选择偏差，
EXEC DBMS_STATS.GATHER_TABLE_STATS可能就解决问题
实际操作中，很多人改完参数忘了重启，或者以为设了会话级就一劳永逸。最稳妥的做法是：先用会话级验证效果，确认无误后再走系统级 + 重启流程，并在重启后立刻查 v$parameter 和 v$sql 验证落地状态。
