物化视图在 PostgreSQL 中需手动创建并显式刷新才生效，且必须建索引、更新统计信息，并通过 EXPLAIN 确认是否被查询重写；预聚合表在固定分组场景下更稳定可控。
物化视图在 PostgreSQL 里怎么建才真正生效
PostgreSQL 本身不原生支持物化视图（MATERIALIZED VIEW），得靠 CREATE MATERIALIZED VIEW 手动创建，但很多人建完发现查询没走它——根本原因是默认不自动刷新，且查询优化器未必会重写 SQL 去命中。
实操建议：
- 建完必须手动执行
REFRESH MATERIALIZED VIEW，否则数据是空的或旧的 - 加索引：物化视图本身不继承源表索引，
CREATE INDEX ON my_mv (group_col)得单独建 - 确认是否被重写：用
EXPLAIN看执行计划里有没有出现你的物化视图名；如果只显示源表，说明优化器没选它，可能因为统计信息过期，先跑ANALYZE my_mv - 别依赖自动刷新：PG 没有
ON COMMIT或定时触发机制，得靠pg_cron扩展或外部调度（如 cron +psql -c "REFRESH MATERIALIZED VIEW ..."）
预聚合表比物化视图更可控的三个场景
当分组维度固定、下游只查几个特定口径（比如“按天+省份+产品线汇总销售额”），预聚合表比物化视图更稳——它不依赖优化器改写，SQL 显式查它就行，也更容易加约束和分区。
实操建议：
- 用
INSERT INTO summary_sales SELECT date_trunc('day', order_time), province, product_line, sum(amount) FROM orders GROUP BY 1,2,3构建初始数据 - 增量更新时，避免全量重算：只处理新数据（
WHERE order_time >= '2024-04-01'）并用ON CONFLICT ... DO UPDATE合并 - 给时间字段加范围分区（
PARTITION BY RANGE (stat_date)），查最近7天报表时能跳过90%分区，速度差一个数量级 - 注意 NULL 处理：分组字段含 NULL 时，
GROUP BY会把它们聚成一组，但业务常要排除，加WHERE province IS NOT NULL更安全
GROUP BY 字段太多导致慢？先看执行计划里的 HashAgg 是否溢出到磁盘
当 GROUP BY a,b,c,d,e 字段多、基数高，PostgreSQL 可能撑不住内存，HashAgg 会写临时文件，I/O 一上来查询就卡住。这不是 SQL 写得不对，是资源瓶颈。
实操建议：
- 查
EXPLAIN (ANALYZE, BUFFERS)输出，重点看有没有disk: xxxkB出现在 HashAgg 行——有就是溢出了 - 调大
work_mem：临时设SET LOCAL work_mem = '256MB'再跑，但别全局改，容易耗尽内存 - 拆分聚合：先按高基数字段（如用户ID）粗聚，再按低基数字段（如状态）细聚，用 CTE 分两步，有时比单次 GROUP BY 快 3 倍
- 确认字段是否真需要：比如
GROUP BY created_at（精确到毫秒）和GROUP BY date(created_at)性能差百倍，业务真要毫秒级分组？
MySQL 8.0 用不了物化视图，但可以靠直连表+覆盖索引硬刚
MySQL 没物化视图，也没 REFRESH 机制，但如果你的报表只读、分组字段稳定，可以用普通表 + 覆盖索引模拟，关键是让 GROUP BY 完全走索引，不回表、不排序、不临时表。
实操建议：
- 建表时字段顺序按分组优先级排：
CREATE TABLE rpt_daily_sale (dt DATE, province VARCHAR(10), product_line VARCHAR(20), amt DECIMAL, PRIMARY KEY (dt, province, product_line)) - 确保
SELECT dt, province, SUM(amt) FROM rpt_daily_sale GROUP BY dt, province能走Using index（看EXPLAIN的Extra列） - 避免
SELECT *：哪怕只多一个没索引的字段，就会触发Using temporary; Using filesort - 定期重建：用
CREATE TABLE rpt_daily_sale_new AS SELECT ... GROUP BY ...，再原子替换（RENAME TABLE），比TRUNCATE + INSERT更少锁表
最麻烦的不是技术选型，是搞清哪些分组维度真的会被高频查询——加一个没用的 GROUP BY user_agent，可能让预聚合表体积翻5倍，而报表里根本没人点开看。
