物化视图加速分组聚合需满足三条件：必须建唯一索引（字段顺序、NOT NULL、覆盖GROUP BY列）、查询结构严格对齐定义（SELECT列/WHERE/GROUP BY完全一致）、PostgreSQL才支持并发刷新；MySQL无原生物化视图，模拟方案存在锁表、延迟、脏数据风险。
物化视图能显著加速大规模分组聚合，但前提是它被真正“查上”——建了不等于用了，用错方式反而白占磁盘、拖慢刷新、还查不到。
PostgreSQL 中必须手动建唯一索引才能并发刷新
没唯一索引的 MATERIALIZED VIEW 无法使用 REFRESH MATERIALIZED VIEW CONCURRENTLY，每次刷新都会锁死整个视图，阻塞所有查询。这不是可选项，是生产环境硬门槛。
- GROUP BY 字段必须能构成业务唯一性，例如
region和EXTRACT(YEAR FROM order_date)联合在业务中不会重复 - 立刻执行：
CREATE UNIQUE INDEX ON mv_sales_by_region_year (region, year)（注意字段顺序必须和 GROUP BY 一致） - 索引列必须为
NOT NULL；如果源字段允许 NULL，需在物化视图定义中用COALESCE(region, 'unknown')处理，否则索引创建失败 - 刷新时若报错
ERROR: cannot refresh materialized view "mv" concurrently because it has no unique index，别改语法，先检查索引是否存在、是否覆盖全部分组列、是否为 UNIQUE
查询结构不匹配 = 物化视图彻底失效
优化器不会“智能推导”你是不是想用物化视图。只要 SELECT 列、WHERE 条件、GROUP BY 字段三者中任一不严格对齐，它就当这张表不存在，继续扫基表。
- 物化视图定义是
SELECT region, SUM(amount) FROM orders GROUP BY region，但你查SELECT region, COUNT(*) FROM mv GROUP BY region WHERE amount > 1000—— 直接失效：多了COUNT(*)，加了不在定义里的WHERE - 别名不一致也会断链：物化视图里写
EXTRACT(YEAR FROM order_date) AS year，你查时用WHERE year = 2026没问题；但若写成WHERE EXTRACT(YEAR FROM order_date) = 2026，优化器无法匹配表达式，跳过物化视图 - 类型隐式转换是隐形杀手：
EXTRACT(YEAR FROM order_date)返回double precision，而你 WHERE 用整数2026，触发隐式转 cast，索引失效，物化视图也失效 - 验证是否命中：运行
EXPLAIN (ANALYZE, VERBOSE) SELECT * FROM mv_sales_by_region WHERE region = 'CN'，输出里必须出现Seq Scan on mv_sales_by_region—— 如果只看到orders表名，说明被内联展开了，没走物化视图
MySQL 用户别硬套物化视图语法
MySQL 官方不支持 CREATE MATERIALIZED VIEW，任何试图用 CREATE TABLE AS SELECT + 定时 TRUNCATE + INSERT INTO ... SELECT 模拟的行为，都面临三个现实问题：锁表、延迟不可控、事务隔离风险。
- 全量刷新时，
TRUNCATE是 DDL，会锁整个表，期间所有读请求等待，QPS 骤降 - 若基表每秒写入百行，定时任务间隔 5 分钟，物化表数据就滞后最多 5 分钟，且无法保证原子性：刷新中途失败，表就处于脏状态
- 更稳妥的替代路径：把聚合逻辑下沉到应用层，比如用 Redis Sorted Set 存每日 region 销售额，写订单时用
ZINCRBY实时更新；或直接换引擎，如 Hologres、ClickHouse 或 PostgreSQL - 如果非要在 MySQL 做，至少用
REPLACE INTO替代TRUNCATE + INSERT，减少锁表时间；并确保SELECT查询走的是新表名，而非原视图名（MySQL 视图无法被物化）
最容易被忽略的点：物化视图不是“设置即忘”的加速开关，它是一张需要持续维护的物理表。刷新频率、索引健康度、基表统计信息是否及时 ANALYZE，三者缺一都会让毫秒级响应退化成秒级扫描。别只盯着建语句，多看 pg_stat_all_tables 里的 last_analyze 和 n_tup_upd。
