物化视图关联源表的外键约束是否影响其查询速度？

背景 #

假设创建如下物化视图：

create materialized view my_mat_view as
select * 
from tb1
join tb2
on tb1.id = tb2.f_id and
tb1.col1 = tb2.col2

核心问题与解答 #

1. tb2是否存在指向tb1的外键约束，对my_mat_view的查询速度有差异吗？ #

没有直接差异。物化视图是预计算并存储结果集的对象，查询它时直接读取存储的物理数据，和源表的外键约束无关。外键约束仅影响源表的数据写入、更新时的完整性校验，以及源表自身查询的优化逻辑，但这些都和物化视图的查询阶段不相关。

2. 物化视图是不是仅在刷新时执行底层构建查询？查询物化视图时的情况如何？ #

没错，物化视图的底层构建SQL（也就是你写的关联查询语句）仅在刷新（全量/增量刷新）阶段执行，执行完成后会把结果集物理存储起来，和普通表的存储逻辑一致。
查询物化视图时，数据库直接读取这张“预存表”的数据，不会再访问源表tb1、tb2，除非触发了刷新操作重新构建数据。

3. 在my_mat_view的tb2外键相关列上创建索引，是否能达到同等效果？ #

如果这里的“同等效果”指提升查询速度，那答案是肯定的。在物化视图的f_id、col2这类列上创建索引，能直接加速针对这些列的过滤、排序、关联查询等操作。但要明确：源表的外键是数据完整性约束，物化视图上的索引是优化自身查询的手段，两者作用对象和场景完全不同，但索引确实能直接提升物化视图的查询效率。

4. 物化视图的源表间建立关联关系，能否提升该物化视图的查询速度？ #

不能直接提升。源表间的关联关系（比如外键、主键关联）只会影响物化视图的刷新阶段：查询优化器可能利用这些关联关系生成更高效的执行计划，让刷新操作更快完成。但一旦物化视图刷新完成，查询它时还是直接读取预存数据，源表的关联关系对查询阶段没有任何影响。

内容的提问来源于stack exchange，提问作者moth