19c物化视图刷新变慢的根源是并行启用、日志结构和统计信息三大条件未满足：必须显式执行alter session enable parallel dml、基表日志含with sequence及including new values、刷新后立即收集mv统计信息。
不是版本升级本身拖慢了刷新，而是19c对并行、日志结构、统计信息和刷新参数更严格——漏掉任一条件，原本在11g里“凑合能跑”的刷新，在19c里就直接退化为串行或COMPLETE，速度断崖下跌。
DBMS_MVIEW.REFRESH默认不再启用并行
11g中某些场景下即使没开ALTER SESSION ENABLE PARALLEL DML，也可能意外触发部分并行；19c彻底收紧，必须显式执行该语句，且只能在同一会话中紧挨着DBMS_MVIEW.REFRESH调用前执行。
- 漏掉这句，哪怕基表加了
PARALLEL 4、物化视图定义里写了PARTITION BY，也全程串行 -
parallelism参数只在atomic_refresh => FALSE时生效；默认TRUE下它只是个摆设，还可能因事务锁导致更慢 - 验证是否真并行：刷新中查
V$PX_SESSION，看到多个Q00x进程才算成功；只看到1个，说明没开起来
日志结构不满足19c的FAST刷新硬要求
11g允许建不含WITH SEQUENCE的日志，但多更新场景结果不可靠；19c虽不报错，却会静默退化为COMPLETE刷新——你以为在增量，实际在全量重刷。
- 必须每张基表日志都含
WITH SEQUENCE和INCLUDING NEW VALUES -
SEQUENCE()里必须包含所有JOIN列、WHERE中引用列、以及物化视图SELECT里的所有列 - 查日志是否合规：
SELECT SEQUENCE, PRIMARY_KEY FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'；若SEQUENCE为NO，FAST刷新不可能生效
刷新后统计信息未更新，导致后续查询计划歪斜
物化视图刷新只是改数据，19c绝不会自动收集其统计信息。旧统计让优化器误判数据量，生成全表扫描、分区全扫等低效计划，连带让下一次刷新SQL也走歪路。
- 刷新完成后立即执行：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'MV_NAME', cascade => TRUE, estimate_percent => 10, method_opt => 'FOR COLUMNS SIZE 254 COL1, COL2') - 别只看基表统计——
DBA_TAB_STATISTICS里确认MV_NAME的LAST_ANALYZED时间是否与刷新时间接近 - 若用预建表（
ON PREBUILT TABLE），统计必须收集到那个物理表名上，不是物化视图名
子查询或复杂表达式让FAST刷新直接失效
19c内核级禁止任何含子查询的物化视图做FAST刷新。只要EXISTS、IN、NOT EXISTS、UPPER()、SYSDATE出现，DBMS_MVIEW.EXPLAIN_MVIEW就返回fastrefreshable = FALSE，刷新时静默切到COMPLETE。
- 用
DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')查RECOMMENDATION字段，比看执行计划更快定位卡点 -
MSGTXT里出现“subquery not supported”或“expression not allowed”，就不用再调参数，得重构SQL - 常见可拆解场景：
EXISTS→ 改INNER JOIN；NOT EXISTS→ 拆成UNION ALL+ 显式主键匹配
真正卡住的从来不是“要不要调大parallelism”，而是ALTER SESSION ENABLE PARALLEL DML有没有执行、日志里SEQUENCE有没有、统计信息有没有在刷新后立刻更新——这三个动作缺一不可，且顺序不能错。
