全量刷新慢的本质是INSERT+DELETE的原子事务开销；启用TRUNCATE模式需设atomic_refresh => FALSE，配合parallelism和错误处理调整，并通过执行计划验证TRUNCATE是否生效。
全量刷新为什么慢？本质是INSERT+DELETE的事务开销
默认情况下，refresh complete走的是“先delete再insert”的原子事务流程，哪怕物化视图有上千万行，oracle也得在单个事务里完成全部删除和重插。这会带来三重压力：大量undo生成、长时间行锁持有、高redo日志写入。尤其当atomic_refresh => true（默认值）时，整个过程无法分段提交，极易触发ora-01555或enq: tx - row lock contention。
TRUNCATE模式怎么开？关键就一个参数
启用真正意义上的TRUNCATE+INSERT，必须显式设置atomic_refresh => FALSE。这不是可选项，而是开关——不设它，parallelism再大也白搭，Oracle照样走DELETE。
-
atomic_refresh => FALSE：触发TRUNCATE操作（快、不产undo），后续INSERT按批提交（默认每5000行commit一次） -
atomic_refresh => TRUE（默认）：强制DELETE+INSERT单事务，锁表时间与数据量正相关 - 注意：该参数只对
COMPLETE和FORCE有效；FAST刷新不受影响
开启TRUNCATE后必须同步调整的参数
光设atomic_refresh => FALSE还不够，否则可能因并发写入冲突或资源争用反而更慢。
-
parallelism => 2~4：配合TRUNCATE后，Oracle能并行INSERT；值超过CPU_COUNT * 2易引发enq: PS - contention - 避免
refresh_after_errors => TRUE：出错时已提交批次无法回滚，物化视图状态不可控 - 确认基表无主键冲突风险：TRUNCATE后INSERT不校验主键重复，若源数据本身脏，会直接报
ORA-00001
监控是否真走TRUNCATE？别信日志，看执行计划
调用DBMS_MVIEW.REFRESH成功不代表TRUNCATE生效。真实行为藏在刷新语句的执行计划里：
- 查最近一次刷新的SQL ID：
SELECT sql_id FROM v$sql WHERE sql_text LIKE '%TRUNCATE%MV_NAME%' - 用
DBMS_XPLAN.DISPLAY_CURSOR('sql_id')看执行计划：出现TRUNCATE TABLE步骤才算成功 - 若执行计划里仍是
DELETE STATEMENT+INSERT AS SELECT，说明atomic_refresh没生效或被其他逻辑覆盖
真正起效的TRUNCATE模式，会让全量刷新从“按秒卡顿”变成“按毫秒响应”，但代价是刷新窗口内查询可能看到空表或部分新数据——这点业务层必须兜底。
