存储过程里SQL从不触发查询重写，因为Oracle默认关闭会话级QUERY_REWRITE_ENABLED，且PL/SQL单元启动时用实例默认值初始化优化器参数，不继承调用方设置；必须在存储过程BEGIN块开头显式执行ALTER SESSION SET QUERY_REWRITE_ENABLED=TRUE，并确保物化视图创建时包含ENABLE QUERY REWRITE子句、权限直授、MV状态为FRESH，否则重写静默失效。
存储过程里执行的SQL为什么从不触发查询重写
因为 oracle 默认关闭会话级 query_rewrite_enabled，而存储过程运行在独立会话上下文中，不会继承调用方的会话设置——哪怕你在 sql*plus 里执行了 alter session set query_rewrite_enabled = true，进到存储过程里它仍是 false。
这不是 bug，是 Oracle 的会话隔离机制决定的：每个 PL/SQL 单元启动时都用实例默认值初始化优化器参数，除非显式覆盖。
- 验证方式：在存储过程中加一句
DBMS_OUTPUT.PUT_LINE(SYS_CONTEXT('USERENV', 'SESSIONID'))，再查V$SES_OPTIMIZER_ENV中该会话的query_rewrite_enabled值，基本都是FALSE - 不能靠角色或应用连接池配置“一劳永逸”，必须在存储过程内部设参
-
ALTER SESSION必须在BEGIN块开头立即执行，放在游标声明之后或异常处理块里就无效
ENABLE QUERY REWRITE 子句在存储过程里没用
物化视图建的时候漏了 ENABLE QUERY REWRITE，就算你在存储过程里把参数设成 TRUE，也白搭。Oracle 不会在运行时动态启用重写能力，只认建表时的定义。
常见误操作：用 CREATE MATERIALIZED VIEW mv AS SELECT ... 直接建完，没加末尾子句；或者建完后想用 ALTER MATERIALIZED VIEW mv ENABLE QUERY REWRITE，但 Oracle 不支持这个语法（会报 ORA-30372: illegal operation on a materialized view）。
- 已有 MV 漏了这个子句？只能
DROP MATERIALIZED VIEW mv后重建，且建语句必须包含ENABLE QUERY REWRITE - 如果 MV 是别人建的，你还得确认它所属 schema 是否已授予你
QUERY REWRITE权限（不是角色，是直授） - 跨 schema 查询时，
GLOBAL QUERY REWRITE权限也必须直授，否则即使参数和定义都对，也会静默跳过
DBMS_MVIEW.EXPLAIN_REWRITE 在存储过程里跑不通
调用 DBMS_MVIEW.EXPLAIN_REWRITE 需要 EXECUTE 权限，且传入的 SQL 字符串不能含绑定变量——而存储过程里几乎全是带 :p_id 这类变量的动态 SQL。
直接拼字符串（如 'SELECT * FROM sales WHERE id = ' || p_id）又带来注入风险，且一旦字段类型是 DATE 或 TIMESTAMP，格式错一个字符就导致匹配失败。
- 调试建议：先在 SQL*Plus 里用硬编码值跑通
EXPLAIN_REWRITE，确认 MV 本身可用；再回到存储过程，把相同逻辑抽成独立函数，在函数里显式设参 + 执行硬编码查询 - 别信
EXPLAIN PLAN FOR输出——它只显示最终选择，不告诉你“有没有尝试重写”。真要看效果，得查V$SQL_PLAN中对应 SQL_ID 的OBJECT_NAME字段是否为 MV 名 - 如果存储过程里用了
EXECUTE IMMEDIATE，记得在它之前加ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE，否则那条动态 SQL 绝对走基表
QUERY_REWRITE_INTEGRITY=ENFORCED 让存储过程更难命中
默认的 ENFORCED 模式下，Oracle 会检查 MV 是否 FRESH、基表是否有主键、物化视图日志是否完备——这些校验在存储过程执行瞬间发生，而刷新作业可能刚失败、日志刚被 truncate、甚至约束刚被 disable。
结果就是：同一段 SQL，在 SQL*Plus 里能重写，在存储过程里却走基表，不是代码问题，是环境状态在毫秒级发生了偏移。
- 临时排查：在存储过程开头加
ALTER SESSION SET QUERY_REWRITE_INTEGRITY = TRUSTED，如果这时重写生效，说明是ENFORCED下某项校验失败 - 别长期设
TRUSTED，它跳过 STALENESS 检查，意味着你得自己确保 MV 刷新及时，否则返回脏数据 - 最稳做法：在存储过程里刷新前加
DBMS_MVIEW.REFRESH('MV_NAME', atomic_refresh => FALSE)，再查STALENESS确保是FRESH，最后才执行目标查询
实际跑通的关键点往往藏在细节里：会话参数重置、权限直授、建 MV 时那个不能省的子句、还有 ENFORCED 模式下对数据新鲜度的零容忍——少一个，重写就静默失效，连错误都不报。
