fast刷新会锁分区基表的行，因需读取mlog$_*日志并回放dml，对被变更行加tx行锁；atomic_refresh=>false可降为瞬时ddl锁，但须确认fast_refreshable=fast且can_use_log=yes，否则退化为complete刷新。
为什么FAST刷新会锁分区基表的行
物化视图本身不锁基表，但FAST刷新时要读取MLOG$_*日志并回放DML（比如对基表某行执行UPDATE），这个过程会对**被变更的具体行**加TX行锁。如果业务系统正对同一分区频繁写入，而刷新又在读取该分区对应日志，就容易形成“业务改A行 → 刷新要删A行 → 双方互等”的阻塞链。这不是表级锁，但足够让业务DML卡在enq: TX - row lock contention上。
atomic_refresh => FALSE真能减少锁影响吗
能，但只在它真正生效的前提下。默认atomic_refresh => TRUE把整个FAST刷新包在一个事务里：DELETE + INSERT全量走一遍，锁持续到事务结束——对千万级分区表，可能锁几十秒甚至更久。设为FALSE后，Oracle改用TRUNCATE + INSERT /*+ APPEND */，锁粒度降为DDL级（仅瞬时），且不依赖UNDO，大幅缩短持锁窗口。
- 必须显式传参：
DBMS_MVIEW.REFRESH('MV_NAME', method => 'F', atomic_refresh => FALSE)，不能靠默认值 - 副作用是刷新期间MV短暂不可用（查时报
ORA-00942），应用层得能接受这个空窗 - 若物化视图实际已退化为COMPLETE刷新（比如日志失效、含聚合函数），这个参数会被静默忽略，锁反而更重
如何确认FAST刷新没退化成COMPLETE
别信创建语句里写的REFRESH FAST，得看Oracle运行时是否真认可。两个关键查询缺一不可：
- 查能力：
SELECT fast_refreshable FROM user_mviews WHERE mview_name = 'MV_NAME'—— 必须返回FAST，不是DIRLOADDML或UNDEFINED - 查日志可用性：
SELECT can_use_log FROM user_mviews WHERE mview_name = 'MV_NAME'—— 必须是YES；再顺手查SELECT log_table FROM user_mview_logs WHERE master = 'PARTITIONED_TABLE_NAME'确认日志存在且未被意外DROP - 如果发现
fast_refreshable是NO，说明基表可能缺主键、ROWID未启用，或日志字段（如SEQUENCE）没覆盖物化视图SQL中用到的列
分区表日志表本身怎么不拖慢刷新
MLOG$_*日志表一旦积压超百万行，FAST刷新第一步“扫描日志找增量”就会卡死——没索引+统计信息过期=全表扫描+磁盘排序。这不是锁问题，但会让刷新长时间占着资源，间接加剧锁冲突。
- 立刻建复合索引：
CREATE INDEX idx_mlog_snap_seq ON MLOG$_PARTITIONED_TABLE (snaptime$$, sequence$$)，顺序不能颠倒 - 更新统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS(user, 'MLOG$_PARTITIONED_TABLE', estimate_percent => 100) - 定期清理：
EXEC DBMS_MVIEW.PURGE_LOG('PARTITIONED_TABLE', 1)（清理1天前日志），避免日志膨胀成定时炸弹
最容易被忽略的是：日志表维护操作（比如基表做ALTER TABLE ... SPLIT PARTITION）会触发日志重建，期间自动对基表加TM模式6锁，所有DML都会被拦住——这和刷新无关，但现象一模一样。
