物化视图刷新慢主因是并行未生效、日志结构不支持FAST、基表索引缺失或参数配错；atomic_refresh=>FALSE必须与parallelism配对使用，否则并行无效，且仅对COMPLETE/FAST刷新生效，含GROUP BY或JOIN时会被Oracle静默忽略。
物化视图刷新慢，90% 不是 SQL 本身写得差，而是并行没生效、日志结构不支持 FAST、基表索引缺失，或刷新参数配错——直接调大 parallelism 或改频率，大概率白忙。
为什么 atomic_refresh => FALSE 必须和 parallelism 配对用
Oracle 默认 atomic_refresh => TRUE，所有并行进程挤在一个事务里等提交，锁、undo、TX 等待全来了；只有设成 FALSE，才真正分批提交（如每 5 万行 commit 一次），释放并行能力。
- 必须在同一会话中先执行
ALTER SESSION ENABLE PARALLEL DML，再调用DBMS_MVIEW.REFRESH -
atomic_refresh => FALSE对method => 'C'和'F'都生效，但对'FAST'刷新无影响 - 若物化视图含
GROUP BY、JOIN或聚合函数，该参数会被 Oracle 忽略，悄悄退回到原子模式 - 刷新期间 MV 可能短暂返回新旧混合数据，业务查询需容忍此窗口
怎么确认物化视图日志（MLOG$_xxx）没拖后腿
哪怕 SELECT COUNT(*) FROM MLOG$_your_table 返回 0，也不代表它没膨胀——高水位线（HWM）悬空才是真问题。
- 查真实空间占用：
SELECT bytes/1024/1024 AS mb FROM dba_segments WHERE segment_name = 'MLOG$_YOUR_TABLE' - 如果 MB 远大于实际行数，执行：
ALTER TABLE MLOG$_YOUR_TABLE ENABLE ROW MOVEMENT，再ALTER TABLE MLOG$_YOUR_TABLE SHRINK SPACE COMPACT - 检查日志是否支持 FAST：
SELECT ROWIDS, SEQUENCE, PRIMARY_KEY FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'，三者必须全为YES - 多表
JOIN场景下，每个基表都要有独立日志，且SEQUENCE()中必须包含JOIN列和ROWID
如何用 DBMS_MVIEW.EXPLAIN_MVIEW 快速定位根因
别急着看执行计划，先跑这个过程——它比 AWR 或 v$session 更早暴露瓶颈点。
- 运行
DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')，结果写入MVIEW_EXPRESS表，查MSGTXT字段 - 常见提示如
"REFRESH FAST IS NOT POSSIBLE"或"NO LOG ON BASE TABLE"比执行计划更早定位根因 - 如果输出里有
"POTENTIAL FAST REFRESH"但实际没走，大概率是基表 DML 后未提交，或 mvlog 被 purge 过 - 刷新 SQL 的执行计划里，盯住对
MVIEW$_xxx表的访问方式：正常应走INDEX RANGE SCANonI_MLOG$_xxx；若出现TABLE ACCESS FULL，说明日志表已失控
PostgreSQL 物化视图并发刷新为何卡住
REFRESH MATERIALIZED VIEW CONCURRENTLY 报错“unique index required”，不是语法问题，而是索引不满足硬性条件。
- 唯一索引必须显式创建（不能靠主键隐含），且列必须
NOT NULL - 索引列顺序必须与
GROUP BY字段完全一致（如GROUP BY department, year，索引就得是(department, year)） - 避免在
GROUP BY中用表达式（如EXTRACT(YEAR FROM order_date)），它无法被索引直接引用 - 没有唯一索引的物化视图，每次
REFRESH都会锁死整个视图，所有SELECT查询被阻塞
最容易被忽略的是：Oracle 的 atomic_refresh => FALSE 在多表 JOIN 或含聚合的场景下会被静默忽略；PostgreSQL 的并发刷新对唯一索引的要求是刚性的，哪怕少一个 NOT NULL 约束，也会退化为全表锁。这些细节不验证，优化就停在纸面。
