一、物化视图基础概念

聊物化视图之前，我先问一个问题：你用过普通视图吗？就是那种 CREATE VIEW 出来的东西。很多人觉得视图挺好用，把复杂查询封装一下，写起来省事。但用过一段时间你就会发现——视图其实只是个「语法糖」。它不存数据，每次查询都重新跑一遍 SQL。

物化视图就不一样了。它真的把数据存下来了。说白了，物化视图就是「用空间换时间」的典型做法。我在项目中遇到过不少团队，查询慢到用户投诉，加索引没用，改 SQL 也没用，最后靠物化视图一把搞定。

1.1 什么是物化视图

物化视图（Materialized View），本质上是一张「预计算」的物理表。它把查询结果提前算好、存下来。你查它的时候，读的是已经算好的数据，不用再跑原始 SQL。

举个例子：

-- 普通视图：每次查询都重新聚合
CREATE VIEW daily_sales_view AS
SELECT date, SUM(amount) AS total
FROM orders
GROUP BY date;

-- 物化视图：数据提前算好，存成物理表
CREATE MATERIALIZED VIEW daily_sales_mv AS
SELECT date, SUM(amount) AS total
FROM orders
GROUP BY date;

嗯，这里要注意：物化视图不是实时数据。它需要刷新策略来保持数据新鲜。StarRocks 支持自动刷新，也支持手动刷新，后面章节我会详细讲。

1.2 物化视图与普通视图的区别

很多初学者容易搞混这两个概念。我整理了一张对比表，你一看就明白：

你想想看，普通视图就像你每天去菜市场买菜，现买现做。物化视图呢，就像周末一次性买好一周的菜，放冰箱里，吃的时候直接热一下。哪个快？当然是后者。

1.3 物化视图的核心价值

物化视图为什么重要？我总结了三个核心价值：

1. 查询加速——这是最直接的价值。预计算把 O(n) 的聚合查询变成 O(1) 的点查。我在项目中见过一个日活报表，原始查询跑 30 秒，建了物化视图后降到 200 毫秒。
2. 降低计算压力——物化视图把计算负担从查询时转移到刷新时。业务高峰期查询不卡顿，底层集群压力也小很多。
3. 简化查询逻辑——复杂的多表 JOIN、多层聚合，封装成物化视图后，业务方只需要 SELECT * FROM mv。你想想看，这能减少多少沟通成本。

1.4 物化视图的核心逻辑

为了让你更直观地理解物化视图的工作流程，我画了一张图：

这张图展示了物化视图的完整生命周期：从基表出发，经过 SQL 定义、刷新机制、物理存储，最终服务查询请求。每一步都有它的设计考量，后面章节我会逐一展开。

1.5 什么时候该用物化视图

根据我的经验，以下场景特别适合物化视图：

• 固定维度的聚合报表——比如每天、每周、每月的销售汇总。维度不变，数据量持续增长。
• 多表 JOIN 后的查询——三张以上的大表 JOIN，每次查询都跑一遍，资源消耗巨大。
• 高频查询的低延迟要求——用户在前端点一下，期望 1 秒内出结果。物化视图能做到。
• 数据仓库的 ETL 中间层——把清洗、转换后的数据存成物化视图，下游直接使用。