物化视图不自动带索引，必须手动创建；它本质是只读物理表，不继承基表索引，需为常用过滤、连接、排序字段显式创建B-tree、BRIN或覆盖索引，并确保enable_material=on、谓词匹配且统计信息更新，否则EXPLAIN仍显示Seq Scan。
物化视图不自动带索引，必须手动创建
PostgreSQL 的 MATERIALIZED VIEW 本质是一张只读的物理表，它不会继承基表的索引，也不会自动生成任何索引。建完 CREATE MATERIALIZED VIEW mv_orders_summary AS ... 后直接查，WHERE 或 ORDER BY 字段若无索引，照样走 Seq Scan —— 这不是语法错，是漏了关键一步。
你得像对待普通表一样，为常用查询路径显式建索引：
- 过滤字段（如
month,region）优先建单列 B-tree 索引 - 高频组合条件（如
WHERE region = '华东' AND month >= '2024-01'）用复合索引，高选择性列放左边 - 若常查
SELECT month, sum_amount FROM mv_orders_summary，考虑加INCLUDE覆盖索引：CREATE INDEX idx_mv_month_sum ON mv_orders_summary (month) INCLUDE (sum_amount)
为什么 EXPLAIN 还显示 Seq Scan？常见三类原因
即使索引已建，EXPLAIN 仍看到全表扫描，大概率卡在这几个环节：
-
enable_material = off（默认值）：PostgreSQL 12+ 需显式开启才能让优化器“看见”物化视图；执行SET enable_material = on;再试 - 谓词不匹配：物化视图定义用的是
date_trunc('month', created_at)，但查询写的是WHERE created_at >= '2024-03-01'，优化器无法推导语义等价，拒绝重写 - 统计信息过期：物化视图刷新后未
ANALYZE mv_orders_summary，优化器误判数据分布，选错执行计划
并发刷新时索引会锁表？得有唯一索引支撑
想用 REFRESH MATERIALIZED VIEW CONCURRENTLY 避免查询阻塞，前提是你已在物化视图上建了**唯一索引**（如基于主键或业务唯一组合）。没有它，PostgreSQL 无法安全比对新旧数据行，只能退回到全量锁表刷新。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
注意点：
- PostgreSQL 物化视图本身不支持
PRIMARY KEY约束，唯一性靠索引保障 - 复合唯一索引更实用，例如
CREATE UNIQUE INDEX uk_mv_order_month ON mv_orders_summary (order_id, month) - 刷新时所有索引都会重建，大视图 + 多索引可能让
REFRESH时间翻倍，别盲目堆索引
BRIN 索引适合时间字段，但别在小物化视图上乱用
如果物化视图按时间聚合（如日/月销售汇总），且数据天然按时间顺序插入，BRIN 索引比 B-tree 更省空间、刷新更快。但它只对“数据物理存储顺序与索引字段逻辑顺序高度一致”的场景有效。
判断是否适用：
- 物化视图行数 ≥ 百万级，且时间字段单调递增（如
report_date） - 查询多为范围（
BETWEEN）、少为等值（=） - 建索引前先确认：
SELECT pg_size_pretty(pg_total_relation_size('mv_orders_summary'));—— 若不到 10MB，BRIN 带来的收益几乎可忽略，反而增加维护复杂度
实际生效的关键往往不在“能不能建”，而在于“建在哪、建多少、建完有没有让优化器认出来”。物化视图的索引不是补丁，是设计闭环里必须前置考虑的一环。
