物化视图本身不自动加速java报表查询，必须同时满足query_rewrite_enabled=true、mv带enable query rewrite、基表有主键或rowid、查询语义匹配这四个硬条件，否则jdbc template执行的参数化sql仍会扫全表。
物化视图本身不自动加速 java 报表查询，必须同时满足 query_rewrite_enabled=true、mv 带 enable query rewrite、基表有主键或 rowid、查询语义匹配这四个硬条件，否则 jdbc template 执行的参数化 sql 仍会扫全表。
QUERY_REWRITE_ENABLED 必须显式开启（不只是建了 MV）
Oracle 默认关闭查询重写，哪怕你 CREATE MATERIALIZED VIEW ... ENABLE QUERY REWRITE 成功，只要 QUERY_REWRITE_ENABLED 是 FALSE，优化器根本不会考虑重写。这不是“建了就生效”，而是“开了才进候选池”。
- 全局开启（需 DBA 权限）：
ALTER SYSTEM SET QUERY_REWRITE_ENABLED = TRUE; - 会话级开启（适合测试）：
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE; - 查当前值：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'query_rewrite_enabled';—— 返回是字符串'TRUE'或'FALSE'，不是布尔值 - 常见坑：Spring Boot 应用用连接池（如 HikariCP），连接复用后不会自动执行
ALTER SESSION；开发环境手动开过，上线后生产库没配，实际仍是FALSE
物化视图必须带 ENABLE QUERY REWRITE 子句（不能靠 hint 补救）
漏掉这个子句，MV 就只是个普通表，/*+ REWRITE */ hint 会被优化器直接忽略——它只建议，不强制。
- 正确写法：
CREATE MATERIALIZED VIEW mv_client_summary REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS SELECT ... - 错误写法：
CREATE MATERIALIZED VIEW mv_client_summary REFRESH COMPLETE ON DEMAND AS SELECT ...（缺ENABLE QUERY REWRITE） - 已有 MV 漏了？不能
ALTER补，只能DROP后重建 - 兼容性要求：基表必须有主键，或 MV 定义中显式包含
ROWID，否则建时会报ORA-30353: expression not supported for query rewrite
Java 参数化查询要能命中 MV，WHERE 和 SELECT 列必须严格语义等价
优化器不做逻辑推导。你查 TO_CHAR(dt, 'YYYY-MM')，MV 存的是原始 dt 字段？不匹配。你加了 ORDER BY，MV 没建对应索引导致排序成本更高？优化器可能主动弃用。
- 可重写的典型场景：
SELECT client_number, SUM(amount) FROM sales WHERE dt >= DATE '2024-01-01' GROUP BY client_number，而 MV 定义为SELECT client_number, dt, SUM(amount) FROM sales GROUP BY client_number, dt（WHERE 条件字段和分组列都在 MV 的 SELECT 列中） - JDBC Template 中的
:phone、:status等绑定变量不影响重写，但函数包装（如UPPER(:phone)）、隐式类型转换（如把字符串'2024-01-01'当日期用）会导致谓词失配 - 验证是否真命中：在应用执行前，先在 SQL*Plus 或 SQL Developer 中执行
EXPLAIN PLAN FOR SELECT ...，再查PLAN_TABLE，看OBJECT_NAME是不是你的 MV 名，而不是原表名
刷新策略直接影响报表数据新鲜度与事务开销
ON COMMIT 虽然实时，但会拖慢基表 DML；ON DEMAND 虽轻量，但报表可能看到过期数据。Java 报表服务常需平衡这两者。
- 高一致性要求（如财务对账）：用
REFRESH FAST ON COMMIT，但必须提前建好物化视图日志（CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY） - 容忍分钟级延迟（如运营日报）：用
REFRESH COMPLETE ON DEMAND+ 定时 Job（DBMS_SCHEDULER.CREATE_JOB），避免影响在线事务 - FORCE 刷新看似省心，但 FAST 不可用时 fallback 到 COMPLETE，可能在高峰期触发长事务阻塞
- 特别注意：JDBC Template 查询若加了
FETCH FIRST N ROWS ONLY，而 MV 没建合适索引，优化器可能因担心排序代价放弃重写
真正卡住 Java 报表性能的，往往不是 MV 没建，而是 QUERY_REWRITE_ENABLED 没开、MV 缺 ENABLE QUERY REWRITE、或者查询里一个 TRUNC(dt) 就让整个重写链路失效——这些点不逐个验证，光看执行计划里有没有 MV 名，容易误判。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
