物化视图不是自动加速器，必须手动刷新才生效；PostgreSQL需执行REFRESH MATERIALIZED VIEW，Oracle需配置QUERY REWRITE，MySQL不原生支持，仅能通过物理表+定时任务模拟。
物化视图不是“自动加速器”，得手动刷新才生效
物化视图（MATERIALIZED VIEW）本身不自动同步数据，它只是把某次查询结果存成一张物理表。PostgreSQL 和 Oracle 会持久化存储，MySQL 直到 8.0.23 才实验性支持，且不支持自动刷新——这意味着你建完 MATERIALIZED VIEW 后，如果源表数据变了，视图内容还是旧的。
常见错误现象：SELECT * FROM daily_sales_summary 返回的是上周数据，但 orders 表里昨天刚插入了新订单。
- PostgreSQL 必须显式执行
REFRESH MATERIALIZED VIEW或REFRESH MATERIALIZED VIEW CONCURRENTLY才能更新 -
CONCURRENTLY模式要求物化视图上已有唯一索引（如PRIMARY KEY (sale_day, product_id)），否则报错ERROR: cannot refresh materialized view "xxx" concurrently - Oracle 需开启
QUERY REWRITE并设置ENABLE QUERY REWRITE，否则优化器不会自动重写查询去读物化视图
为什么 GROUP BY 视图慢？因为聚合总在 JOIN 之后做
普通视图里写 SELECT u.name, SUM(o.amount) FROM users u JOIN orders o ON u.id = o.user_id GROUP BY u.id，每次查询都会完整执行整个流程：先笛卡尔拼接、再过滤、再分组。哪怕你只查最近 7 天的数据，数据库也得先把所有历史订单和用户连一遍，再 WHERE 过滤——中间结果可能几十万行，最后只剩几百个分组。
真正卡顿的根源不是没加索引，而是聚合时机太晚。
- 正确做法是把聚合逻辑从视图中剥离，提前固化：先按业务维度（如
user_id,date(order_time)）在物理表里算好，再让视图或查询轻量关联 - 例如建表
orders_daily_summary，主键设为(user_id, order_date)，字段含total_amount,order_count - 用
INSERT ... ON DUPLICATE KEY UPDATE做幂等写入，避免重复计算
MySQL 没有真正可用的物化视图，别白费劲建索引视图
MySQL 不支持 MATERIALIZED VIEW，也不支持带 GROUP BY 的索引视图（CREATE VIEW ... WITH SCHEMABINDING 在 MySQL 里根本不存在）。你看到的“索引视图”教程，基本都是 SQL Server 写法，照搬到 MySQL 会直接报错。
常见错误现象：执行 CREATE INDEX idx_vw ON my_view(col) 报错 ERROR 1347 (HY000): 'db.my_view' is not BASE TABLE。
- MySQL 下唯一可控方案是建普通物理表 + 定时任务（
crontab或事件调度器EVENT）刷新 - 刷新语句必须包含明确的
WHERE条件，比如只刷昨日数据：WHERE order_time >= CURDATE() - INTERVAL 1 DAY，避免全表扫描 - 别用
SELECT *插入汇总表，字段顺序、类型、NULL 性必须与目标表严格一致，否则ON DUPLICATE KEY UPDATE失效
并发刷新物化视图时，唯一索引是硬门槛
PostgreSQL 的 REFRESH MATERIALIZED VIEW CONCURRENTLY 看似能不锁表，但前提是物化视图定义里必须包含唯一约束，且该约束覆盖所有分组键。漏掉这个，就会退化成阻塞式刷新，高峰期可能拖垮报表服务。
容易踩的坑：CREATE MATERIALIZED VIEW daily_sales_summary AS SELECT product_id, date(order_time), sum(amount) FROM orders GROUP BY product_id, date(order_time); —— 这个定义没指定主键，后续无法并发刷新。
- 必须补上唯一索引：
CREATE UNIQUE INDEX idx_daily_summary_pk ON daily_sales_summary (product_id, sale_day); - 索引列顺序要和
GROUP BY顺序一致，否则某些版本 PostgreSQL 不认 - 如果分组键本身不唯一（比如允许同天同商品多条记录），需加
ROW_NUMBER()或用DISTINCT ON预处理，否则建索引失败
物化视图真正的复杂点不在创建，而在刷新策略与业务节奏的对齐——是每小时全量刷一次，还是只增量合并变更日志？这取决于你能容忍多久的数据延迟，以及源表变更频率是否稳定。一旦选错，要么查不到最新数据，要么刷新过程吃光 I/O 资源。
