普通视图不存数据、每次查询重执行sql，物化视图落地存储、查询快但需刷新；刷新默认锁表，加concurrently可避免但需唯一索引；物化视图可建索引加速查询，普通视图不可；普通视图在满足条件下可写，物化视图只读；刷新频率须匹配业务延迟要求。

普通视图每次查询都重跑 SQL，物化视图查的是落地的快照

普通视图（CREATE VIEW）不存数据，只存一条 SELECT 语句；每次 SELECT * FROM v_name，数据库就原样展开、重新执行那条 SQL。物化视图（CREATE MATERIALIZED VIEW）则真正在磁盘上建了一张表，创建时就执行并保存结果——后续所有查询都直接读这张物理表，跳过原始 JOIN、聚合或过滤逻辑。

这意味着：一个含 5 张表 JOIN + GROUP BY 的视图，普通写法每次查都要算一遍；物化写法查得快，但数据可能已过期。选错类型，要么卡死接口，要么报表数字对不上。

REFRESH MATERIALIZED VIEW 默认会锁表，加 CONCURRENTLY 才能不阻塞查询

REFRESH MATERIALIZED VIEW mv_orders 是原子操作：先清空旧数据，再 INSERT 新结果。在此期间，任何新查询都会被挂起，直到刷新完成——这是线上服务突然抖动的常见原因。

想避免阻塞？必须加 CONCURRENTLY：

REFRESH MATERIALIZED VIEW CONCURRENTLY mv_orders;

但前提是该物化视图已有唯一索引（如主键或 UNIQUE 列），否则报错：ERROR: cannot refresh materialized view "mv_orders" concurrently。没有唯一索引时，要么先建索引，要么接受短暂锁表。

物化视图能建索引，普通视图不能

CREATE INDEX idx_mv_status ON mv_orders (status) 这种操作只对物化视图有效。因为它是真实表，索引能加速 WHERE、ORDER BY 或 JOIN；而普通视图只是 SQL 文本，数据库无法在其上建索引——你给视图建索引，实际建在基表上，和视图本身无关。

但注意：索引不是越多越好。如果物化视图每小时刷新一次，却为每个字段都建了索引，反而拖慢刷新、浪费空间。优先为高频过滤/排序字段建索引，比如 region、created_at。

普通视图有时可写，物化视图一律只读

满足条件的普通视图（单表、无聚合、无 DISTINCT、SELECT 列包含主键）支持直接 UPDATE 或 INSERT，操作会透传到底层基表。例如：

CREATE VIEW active_users AS SELECT id, name, email FROM users WHERE status = 'active';<br>UPDATE active_users SET email = 'new@x.com' WHERE id = 123;

物化视图完全不可写：INSERT INTO mv_orders ... 会直接报错。它本质就是一张只读表，所有更新只能靠 REFRESH 完成。

真正容易被忽略的是“刷新时机”——业务要求数据延迟 ≤ 1 分钟，却用每天凌晨 2 点定时刷新，这种配置比不用物化视图还危险。刷新频率必须和业务容忍度对齐，而不是图省事设成固定 cron。