根本原因是物化视图日志（mlog$_xxx）缺乏有效索引、基表缺失主键/rowid支持，导致merge退化为全表扫描和锁等待；需检查执行计划中是否出现table access full，确认mlog$_xxx索引及基表约束是否完备。
为什么物化视图刷新时的MERGE语句执行变慢
根本原因不是MERGE本身慢，而是物化视图刷新生成的MERGE语句访问了未优化的基表或MVIEW$_临时维护表，尤其当物化视图日志（MLOG$_xxx）缺乏索引、或基表缺少主键/ROWID支持时，MERGE会退化为全表扫描+大量锁等待。
检查MERGE实际执行计划里的关键线索
物化视图刷新本质是Oracle自动生成一段MERGE（或INSERT/UPDATE/DELETE组合），它的性能瓶颈藏在真实执行计划里，而不是DBA_MVIEWS定义中。
- 用
SELECT sql_id FROM v$sql WHERE sql_text LIKE '%MERGE%INTO%MV_%'定位最近一次刷新语句 - 查
DBMS_XPLAN.DISPLAY_CURSOR('sql_id')，重点看TABLE ACCESS FULL是否出现在MVIEW$_xxx或基表上 - 正常应看到
INDEX RANGE SCANonI_MLOG$_xxx（物化视图日志索引），若没有，说明日志表无有效索引 -
ACCESS_PREDICATES为空或只含ROWID，往往意味着谓词无法下推，MERGE被迫读全量变更记录
物化视图日志（MLOG$_xxx）没索引是最常见根因
Oracle在ON COMMIT或FAST刷新时，MERGE需从MLOG$_xxx中快速捞出本次提交的增量行。但MLOG$_xxx默认只有主键（SEQUENCE$$, SNAPTIME$$），没对CHANGE_VECTOR$$或业务列建索引，高并发DML下就会全表扫描+磁盘排序。
- 确认日志表名：
SELECT log_table FROM user_mviews WHERE mview_name = 'MV_NAME' - 查缺失索引：
SELECT index_name FROM user_indexes WHERE table_name = 'MLOG$_MV_NAME'，若返回空或仅含系统默认索引，就危险 - 手动加索引：
CREATE INDEX idx_mlog_mvname_chg ON mlog$_mv_name(change_vector$$) TABLESPACE users（按实际变更向量字段调整） - 注意：索引必须包含
SEQUENCE$$和SNAPTIME$$才能支撑快速定位，单列索引效果有限
基表主键或ROWID缺失导致MERGE退化为COMPLETE刷新
一旦DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')返回"REFRESH FAST IS NOT POSSIBLE"，后续所有刷新都会走COMPLETE路径——即删光再重插，此时MERGE变成全量重建，耗时陡增且锁表。
- 基表必须有
PRIMARY KEY或UNIQUE NOT NULL约束，否则ON COMMIT和FAST刷新直接失效 - 物化视图日志必须显式启用
WITH ROWID和PRIMARY KEY：CREATE MATERIALIZED VIEW LOG ON base_table WITH ROWID, PRIMARY KEY - 如果基表是分区表，还需确保
ROWID在分区键变化时仍稳定，否则MERGE可能误判变更范围 - 检查
USER_MVIEW_LOGS中ROWIDS和PRIMARY_KEY列为YES，否则刷新逻辑会绕过增量路径
真正卡住MERGE的，往往不是SQL写得不好，而是MLOG$_xxx上没索引、基表缺主键、或者日志里积压了未消费的变更记录——这些细节在v$session里只显示为enq: TX或library cache lock，不深挖执行计划和日志结构，永远找不到源头。
