2. StarRocks 物化视图架构：存储、更新与查询路由

这一章，我们来聊聊物化视图的底层架构。说白了，就是搞清楚三件事：数据怎么存、怎么刷新、查询怎么找到它。

我刚开始接触 StarRocks 物化视图时，也踩过不少坑。比如明明建了物化视图，查询却没加速；或者数据更新后，视图还是旧的。后来把架构理清了，这些问题就迎刃而解了。

2.1 存储结构：物化视图到底长什么样？

很多人以为物化视图就是一张「特殊的表」。嗯，这个理解基本正确。但它的存储结构，其实和普通表有本质区别。

StarRocks 的物化视图，底层是一张独立的物理表。它有自己的数据文件、索引和元数据。你想想看，如果它只是逻辑映射，那查询加速从哪来？

具体来说，存储结构包含三个层次：

• 基表数据：原始数据仍然在基表中完整保留。
• 物化视图数据：按照 SELECT 语句中的聚合、排序、分区规则，重新组织后的数据。
• 元数据映射：记录物化视图与基表的字段对应关系、刷新策略、版本号等。

我在项目中遇到过一个问题：一个物化视图占用了大量磁盘空间。后来发现，是因为没有合理设置分区键，导致数据冗余。所以，分区策略直接影响存储效率。

2.2 更新机制：数据变了，视图怎么办？

这是物化视图最核心的难点。基表数据在变，物化视图怎么同步？

StarRocks 提供了两种更新模式：

更新模式	触发方式	适用场景	一致性保证
异步刷新	手动执行 REFRESH MATERIALIZED VIEW	数据延迟可接受，如 T+1 报表	最终一致性
同步刷新	基表数据变更时自动触发	实时性要求高，如实时大屏	强一致性

我个人习惯用异步刷新。为什么呢？因为同步刷新对写入性能有影响。你想想看，每次插入数据都要触发物化视图重算，写入延迟会明显增加。

刷新机制的核心是增量更新。StarRocks 会记录基表的变更日志（类似 binlog），只将增量数据合并到物化视图中。而不是全量重算——那样太慢了。

具体流程如下：

1. 基表数据发生 INSERT/UPDATE/DELETE
2. StarRocks 记录变更的版本号
3. 刷新时，读取版本号之间的增量数据
4. 将增量数据与物化视图现有数据合并
5. 更新物化视图的元数据版本号

这里有个细节：如果物化视图的聚合粒度比基表粗（比如按天聚合），增量更新会非常高效。但如果聚合粒度相同，增量更新的优势就不明显了。

2.3 查询路由原理：查询怎么知道走物化视图？

这是很多人困惑的地方。我建了物化视图，查询 SQL 没改，它怎么就自动加速了？

答案在查询优化器里。StarRocks 的优化器在做查询计划时，会做一件事：物化视图匹配。

匹配过程大致如下：

• 解析查询 SQL，提取查询的字段、过滤条件、聚合函数
• 遍历所有物化视图的元数据
• 判断物化视图是否能覆盖查询的全部或部分需求
• 如果能覆盖，将查询路由到物化视图
• 如果不能完全覆盖，可能走「基表 + 物化视图」的混合路径

匹配规则有几个关键点：

匹配维度	说明	常见失败原因
字段匹配	查询的字段必须在物化视图的 SELECT 列表中	漏选了字段
聚合匹配	查询的聚合函数必须与物化视图一致	用了 COUNT(DISTINCT) 但物化视图是 COUNT
过滤匹配	查询的 WHERE 条件必须在物化视图的范围内	过滤条件超出了物化视图的分区范围
维度匹配	查询的 GROUP BY 字段必须是物化视图的子集	GROUP BY 多了字段

为什么会匹配失败？我遇到过最典型的情况：查询中用了函数包裹字段。比如物化视图里是 date 字段，查询里写的是 DATE_FORMAT(date, '%Y-%m')，优化器就匹配不上了。

下面这张图展示了完整的查询路由流程：

从图中可以看到，匹配成功是理想情况。但实际项目中，匹配失败的情况更常见。我建议你养成一个习惯：每次建完物化视图，都用 EXPLAIN 验证一下查询是否命中。

2.4 架构总结：三者的关系

存储结构、更新机制、查询路由，这三者不是孤立的。它们的关系是这样的：

• 存储结构决定了物化视图能存什么、怎么存
• 更新机制决定了数据怎么从基表同步到物化视图
• 查询路由决定了查询怎么找到最合适的物化视图

说白了，存储是基础，更新是保障，路由是价值。没有合理的存储，更新再快也没用；没有高效的更新，路由到了也是旧数据；没有正确的路由，物化视图就白建了。