物化视图应建在满足GROUP BY维度固定、WHERE条件可收敛、聚合逻辑稳定不变三个硬条件的查询上；否则易导致无效甚至性能下降。
物化视图该不该建？先看查询是否符合三个硬条件
不是所有慢查询都适合上物化视图。真正值得物化的，必须同时满足：GROUP BY维度固定、WHERE条件可收敛、聚合逻辑稳定不变。比如每天查“各省各品类销量总和”，维度是province + category + date，过滤条件始终是order_date >= '2026-07-01'——这种才适合。而“任意时间范围+动态下钻到SKU”的查询，物化视图一建就废。
常见错误现象：建完物化视图后查询没变快，甚至更慢。原因往往是原SQL带了TO_CHAR(order_time)或UPPER(name)这类不可重写函数，导致优化器直接绕过物化视图。
- 检查执行计划：运行
EXPLAIN ANALYZE，确认是否出现MATERIALIZED VIEW字样或访问的是物化表名 - 避免在定义中使用非确定性函数（如
NOW()、RANDOM()） - Oracle/PostgreSQL要求基表有主键或唯一约束，否则
FAST REFRESH或CONCURRENTLY会失败
PostgreSQL里怎么安全刷新物化视图？别用默认REFRESH
REFRESH MATERIALIZED VIEW会锁表，高峰期执行等于主动拖慢业务。真正可用的是REFRESH MATERIALIZED VIEW CONCURRENTLY，但它有个死条件：物化视图必须有唯一索引。
实操建议：
- 建物化视图后立刻加唯一索引，例如：
CREATE UNIQUE INDEX idx_mv_daily ON daily_sales_summary (sale_day, product_id) - 增量刷新靠自己拼：PostgreSQL不原生支持
FAST，得用INSERT ... ON CONFLICT DO UPDATE合并增量日志表，日志表字段要和物化视图对齐 - 刷新任务别堆在整点：凌晨2:17比2:00更安全，错开其他ETL作业高峰
- 大表（>5000万行）刷新前先
VACUUM ANALYZE物化视图，避免统计信息过期导致执行计划劣化
MySQL用户注意：没有原生物化视图，但可以低成本模拟
MySQL 8.0.23+仍不支持CREATE MATERIALIZED VIEW语法。强行用普通表+定时任务也能达到90%效果，关键是把“刷新”做成原子操作。
典型做法：
- 建两张表：
sales_summary_curr（当前生效）和sales_summary_next（正在刷新） - 定时任务用
INSERT INTO sales_summary_next SELECT ...全量重建，完成后RENAME TABLE原子切换 - 应用层只读
sales_summary_curr，切换瞬间无感知 - 别用
TRUNCATE + INSERT，中间空窗期会导致查询返回空结果
数据新鲜度怎么控？延迟不是越小越好
物化视图最大的坑不是性能差，而是数据“看起来对、其实错”。比如T+1报表凌晨2点刷新，但业务方下午还在查“今日实时销量”，这时候查物化表就是错的。
解决思路不是拼命提频次，而是分层暴露：
- 在物化表里加
update_time字段，应用层查完先比对update_time < now() - INTERVAL '1 hour'再决定是否告警 - 用视图封装：视图内部判断查询时间范围，近期数据走明细表，历史数据走物化表
- 缓存层配合：物化表刷新完成，立刻
DEL report:sales:*202607*，而不是等TTL自然过期
真正难的从来不是建一张表，而是让下游系统相信这张表里的数据“此刻该信多少”。
