yashandb物化视图查询重写依赖严格文本匹配，列名大小写、引号、通配符均需完全一致；oracle则基于语义验证，受_query_rewrite_validation参数控制校验强度，与分区裁剪无关。
yashandb 和 oracle 的物化视图查询重写机制完全不同，但用户常把两者混淆——oracle 不会因为分区裁剪失败就导致重写失效，而 yashandb 的重写失败往往跟列名大小写和引号强绑定，跟分区本身无关。如果你在 yashandb 上遇到「分区表 + 物化视图 + 查询不重写」，大概率不是分区的问题，而是列名匹配没对上。
YashanDB 中 select * 创建的物化视图为什么永远不被重写？
根本原因是：YashanDB 当前版本（截至 2025 年 4 月）的查询重写器只做**严格文本匹配**，不解析语义。当你写 select * from test，系统内部展开为 select "TID", "TNAME"（带双引号的大写），但以下所有写法都无法匹配：
-
select tid, tname from test（小写无引号） -
select TID, TNAME from test（大写无引号） -
select * from test（通配符，不展开为具体列）
哪怕表结构完全一致、谓词完全相同，只要列名字符串不逐字相等，重写就直接跳过。
Oracle 的 _query_rewrite_validation 参数影响什么？
这个隐含参数控制 Oracle 优化器验证物化视图是否能安全重写的严格程度，默认值是 ENFORCED。它不决定“是否启用重写”，而是决定“在什么条件下跳过重写”：
-
ENFORCED：强制校验物化视图内容与基表一致性，比如检查STALENESS状态、是否DISABLE ON QUERY COMPUTATION；若物化视图陈旧或定义受限，直接禁用重写 -
TRUSTED：跳过部分一致性检查，假设物化视图数据可信；适用于你手动维护、确保刷新及时的场景 -
OFF：彻底关闭验证逻辑（不推荐，可能返回错误结果）
注意：_query_rewrite_validation 对分区裁剪无影响，它只管重写逻辑本身的可信度。分区是否 prune，取决于 WHERE 条件能否下推，和该参数无关。
为什么在 YashanDB 上加了 enable query rewrite 还是不生效？
YashanDB 的重写开关有两个层级，缺一不可：
- 实例级：必须执行
alter system set query_rewrite_enabled = force scope=both（force比true更激进） - 物化视图级：创建后要显式执行
alter materialized view mv_name enable query rewrite
但即使都开了，仍可能失败——因为 YashanDB 当前不支持对含函数、类型转换、别名的查询做重写。例如：
-
select upper(tname) from test where tid = 66→ 不重写（函数包裹列） -
select t.tid from test t where t.tid = 66→ 不重写（用了别名t，而物化视图里没别名） -
select tid + 0 from test where tid = 66→ 不重写（表达式计算）
如何快速验证当前查询是否命中物化视图？
不要依赖执行计划里有没有出现物化视图名，YashanDB 的执行计划目前不暴露重写痕迹。可靠方法只有两个：
- 查
v$mvrefresh或dba_mview_analysis（如果版本支持），看最近是否有重写调用记录 - 最直接：在会话中开启 SQL 跟踪，执行查询后搜日志里有没有
query rewrite或mv_1字样
Oracle 可用 EXPLAIN PLAN FOR ...; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); 看是否出现 MATERIALIZED VIEW REWRITE 行；但 YashanDB 不输出这类提示，这点容易误判。
真正麻烦的不是配置多难，而是 YashanDB 把重写变成了“字符串对齐游戏”：建 MV 时怎么写，查的时候就得一模一样地写，连空格都不能多一个。这不是优化器能力问题，是当前实现层面的硬约束。
