物化视图能加速查询，但前提是查询模式稳定、基表更新不频繁，并需手动创建索引、开启查询重写且合理配置刷新策略；否则可能比原始查询更慢。
物化视图真能加速查询吗？先看它到底存了什么
物化视图不是普通视图的“升级版”，而是把 SELECT 结果实际写入磁盘的一张物理表。PostgreSQL 的 MATERIALIZED VIEW、Oracle 的物化视图、SQL Server 的索引视图（CREATE VIEW ... WITH SCHEMABINDING + 聚簇索引）都属于这类。它加速的前提是：查询模式稳定、基表更新不频繁、且你愿意用存储空间和刷新延迟换读取性能。
- 普通视图每次执行都是重跑底层 SQL，物化视图则跳过解析、优化、执行阶段，直接查本地数据
- PostgreSQL 中必须手动
REFRESH MATERIALIZED VIEW，默认不自动同步；Oracle 可配ON COMMIT或定时刷新，但会拖慢 DML - 如果基表每天只凌晨批量更新一次，而白天有上百个报表反复查相同聚合结果，物化视图就非常合适；反之，如果订单表每秒插入 500 行，还建物化视图做实时统计，反而成为瓶颈
哪些字段该加索引？别只盯着主键
物化视图本身是一张表，但默认没有索引——它不会继承基表的索引，也不会自动创建任何索引。你得像对待普通表一样，为常用过滤、连接、排序字段显式创建索引。
- 常见误操作：建完
CREATE MATERIALIZED VIEW mv_sales_by_month AS SELECT month, region, SUM(amount) FROM sales GROUP BY month, region;后就以为完事了，结果WHERE month = '2024-03'还是全表扫描 - 正确做法：立刻补上
CREATE INDEX idx_mv_sales_month ON mv_sales_by_month (month);；若常按 region + month 查询，用复合索引idx_mv_sales_region_month - 注意 PostgreSQL 中物化视图不支持唯一约束或主键（除非用
CREATE TABLE AS模拟），所以唯一性需靠业务逻辑或额外检查 - 索引不是越多越好：每个索引增加 INSERT/UPDATE/REFRESH 开销，物化视图刷新时要重建所有索引，大视图+多索引可能让刷新耗时翻倍
为什么用了物化视图，EXPLAIN 还显示 Seq Scan？
这通常不是语法错误，而是查询优化器“没选上”物化视图——它根本没被当作可选对象参与计划生成。
- PostgreSQL 12+ 支持“自动重写”（
ENABLE/DISABLE REWRITE），但默认关闭；必须设SET enable_material = on;（会话级）或在postgresql.conf中开启，否则优化器连物化视图的存在都不知道 - 更隐蔽的问题：查询中的谓词与物化视图定义不匹配。例如物化视图是
GROUP BY date_trunc('day', created_at)，但你查WHERE created_at >= '2024-03-01'，优化器无法确认语义等价，就不会重写 - Oracle 中需确保物化视图满足
QUERY REWRITE ENABLED，且用户有QUERY REWRITE权限；SQL Server 索引视图要求查询必须“精确匹配”视图定义中的表达式（比如不能用SELECT *，必须列全名）
替代方案：普通视图 + 基表索引有时更轻量
不是所有复杂查询都值得上物化视图。如果基表本身已有合理索引、数据量中等（千万行以内）、且查询频率不高（如后台导出任务每天一次），强行物化反而增加运维负担。
- 先用
EXPLAIN (ANALYZE, BUFFERS)看清慢在哪：是 JOIN 顺序不对？缺少连接字段索引？还是聚合函数没走索引扫描？ - 对于含
JOIN+WHERE+GROUP BY的视图，优先确保各基表在关联字段（如order.user_id、user.id）上有索引，且统计信息最新（ANALYZE） - 如果只是想避免重复写长 SQL，普通视图 + 应用层缓存（如 Redis 存结果）可能比物化视图更灵活——尤其当参数动态变化（如不同时间范围、不同地区筛选）时，物化视图难以覆盖全部组合
物化视图不是银弹，它的价值高度依赖刷新策略与查询稳定性。一个没配索引、没开重写、又高频刷新的物化视图，可能比原始查询还慢。
