物化视图不支持直接用子查询做增量刷新，因子查询多含非确定性逻辑，导致Oracle报ORA-12015、Snowflake禁止使用；可行方案是将子查询逻辑移出MV定义，改用MV日志、窗口函数、临时表或TASK+CHANGE TRACKING等命令式增量流程实现。
物化视图不支持直接用子查询做增量刷新
绝大多数数据库（如 Oracle、PostgreSQL 的 MATERIALIZED VIEW 扩展、Snowflake）的物化视图机制，**不接受含非确定性子查询的定义语句用于自动增量刷新**。比如写一个带 (SELECT MAX(updated_at) FROM log_table) 的子查询，Oracle 会报 ORA-12015: cannot create a fast refresh materialized view from a complex query；Snowflake 则根本不允许在 CREATE MATERIALIZED VIEW 中使用子查询引用外部表——它只认静态 SQL 结构。
真正能走增量路径的，是依赖「日志表 + 主键/时间戳 + 可识别变更」的显式逻辑，而不是靠子查询“现场算”。
Oracle 快速刷新必须满足的子查询替代条件
如果你坚持在 Oracle 物化视图中模拟“子查询效果”，得把子查询逻辑拆解成满足 FAST REFRESH 要求的结构。核心不是“能不能写子查询”，而是“能不能让 MV 日志识别出哪些行变了”。
-
主表必须有 MV 日志，且启用ROWID和SEQUENCE（CREATE MATERIALIZED VIEW LOG ON t WITH ROWID, SEQUENCE (id, updated_at) INCLUDING NEW VALUES;） - 子查询若用来过滤最新数据（例如 “取每个 user_id 最新一条记录”），不能直接写
WHERE (user_id, updated_at) IN (SELECT user_id, MAX(updated_at) ...)—— 这触发全量重算；应改用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC)窗口函数，并确保该列参与FAST REFRESH的 join key 或 filter 条件 - 所有关联表必须也建 MV 日志，且 join 条件必须是等值、不可为空（
NOT NULL字段），否则降级为 complete refresh
PostgreSQL 使用 pg_cron + 部分更新绕过子查询限制
PostgreSQL 原生无物化视图增量刷新能力，但可用 REFRESH MATERIALIZED VIEW CONCURRENTLY 配合定时任务实现近似效果。关键在于：**把子查询逻辑移到刷新前的临时表或 CTE 中，而非物化视图定义里**。
例如想“只刷新过去 1 小时有变更的用户聚合”：
CREATE TEMP TABLE recent_users AS SELECT DISTINCT user_id FROM events WHERE event_time > NOW() - INTERVAL '1 hour'; <p>REFRESH MATERIALIZED VIEW CONCURRENTLY user_summary WITH DATA -- 注意：这里不能写子查询，但可以用 recent_users 做 JOIN 或 EXISTS -- 所以实际刷新逻辑要提前准备好中间状态
更稳妥的做法是用 pg_cron 定时执行一段 PL/pgSQL，先 truncate+insert into 临时汇总表，再原子替换视图底层表（通过 ALTER MATERIALIZED VIEW ... SET TABLESPACE 不可行，需用表交换技巧）。
Snowflake 中用 TASK + CHANGE TRACKING 模拟子查询增量
Snowflake 的 MATERIALIZED VIEW 本身不支持自定义刷新逻辑，但它提供 CHANGE TRACKING 和 TASK，可以组合出“子查询意图”的增量行为。比如你想“每次只合并新增/修改的订单及其客户信息”，就不能在 MV 定义里写 (SELECT ... FROM customers WHERE id IN (SELECT DISTINCT customer_id FROM orders ...))，而应该：
- 对
orders和customers表都启用CHANGE TRACKING = TRUE - 建一个
TASK，每次运行时查SYSTEM$CHANGES获取两表的变更 delta，存入 staging 表 - 用
MERGE INTO summary_mv USING staging_delta ...手动 upsert —— 这里才能自由写子查询，因为是 DML，不是 MV 定义
这个模式下，“子查询”出现在 merge 的 USING 子句或 CTE 中，完全可控；而物化视图只是最终结果容器，不承担计算逻辑。
最常被忽略的一点：所有数据库中，所谓“子查询实现增量”，本质都是把查询逻辑从声明式 MV 定义里移出来，变成命令式、可审计、可分步调试的刷新流程。强行塞进 MV 定义，只会换来隐式全量刷新或刷新失败。
