能，物化视图本质是物理表，必须建索引以避免全表扫描；索引应按实际查询模式建在WHERE、JOIN、GROUP BY、ORDER BY相关列及分组键上；日志表索引不影响查询性能；COMPLETE刷新索引有效，FAST刷新通常不受影响，但ON PREBUILT TABLE或分区交换后需手动重建失效索引。
物化视图本身能建索引吗？
能，而且**必须建**——物化视图本质是一张物理表（在 user_tables 中可查），所以支持所有普通表的索引操作。不建索引的物化视图，查询时可能退化为全表扫描，完全浪费预计算优势。
常见误区是以为“物化视图自带优化”，其实它只解决“算得快”，不解决“查得快”。索引才是让后续查询命中数据块的关键。
该在哪些列上建索引？
不是照搬基表索引，而是紧扣物化视图的**实际查询模式**。重点考虑：
- WHERE 条件中高频出现的列（如
status、create_date） - JOIN 或 GROUP BY 中用到的列（如
dept_id、product_category） - ORDER BY 或分页（
FETCH FIRST N ROWS）依赖的排序列 - 物化视图定义里 SELECT 出来的列，但基表上没有对应索引的——比如聚合字段
sum(sales)本身不能建索引，但其分组键region必须有
示例：若物化视图定义为 select region, sum(amount) from sales group by region，则应在 region 上建 B-tree 索引；若常按时间范围过滤，再加一个 (region, sale_date) 复合索引。
为什么物化视图日志上的索引没用？
物化视图日志（MLOG$_xxx 表）是 Oracle 内部维护的变更记录表，它的索引只服务于 FAST 刷新过程，**不影响物化视图本身的查询性能**。
容易踩的坑：
- 误以为给日志表建了索引，物化视图查询就变快——完全无关
- 删除物化视图后，日志表和它的索引残留，占用空间且无意义
- 日志表默认只有
SNAPTIME$$和SEQUENCE$$字段，不带业务字段，建索引价值极低
真正要关注的，永远是物化视图本体（即 user_tables 中那个同名对象）上的索引。
刷新后索引会失效或需要重建吗？
COMPLETE 刷新会 truncate + insert，此时索引自动保持有效，无需干预；FAST 刷新只改增量数据，索引结构不受影响。
但要注意两个边界情况：
- 如果物化视图用了
ON PREBUILT TABLE，且底层表被手动ALTER TABLE ... MOVE过，索引会失效（STATUS = UNUSABLE），必须ALTER INDEX ... REBUILD - 分区物化视图做分区交换（
EXCHANGE PARTITION）后，局部索引可能变为UNUSABLE，需单独 rebuild 对应分区索引 - Oracle 19c+ 中，如果启用了自动索引（Auto Indexing），它**不会**为物化视图生成索引——这是明确限制，必须手动创建
最稳妥的做法：每次 COMPLETE 刷新后，用 SELECT index_name, status FROM user_indexes WHERE table_name = 'MV_NAME' 检查状态，别依赖“应该没问题”这种假设。
