物化视图加速聚合的关键是显式建索引、合理刷新及确保查询能命中视图；分区表聚合慢主因是分区裁剪失效，需避免在分区键上使用函数导致无法pruning。
物化视图在 PostgreSQL 里怎么建才真正加速聚合？
PostgreSQL 本身不原生支持自动刷新的物化视图（直到 v9.3+ 才有 MATERIALIZED VIEW），但即使建了，如果没配好刷新策略，查询时还是可能扫全表。关键不是“建没建”，而是“查的时候用不用得上”。
常见错误现象：EXPLAIN 显示依然走 Seq Scan，或者 SELECT COUNT(*) FROM mv_name 比直接查原表还慢。
- 必须显式创建索引：物化视图默认不带索引，
CREATE INDEX ON mv_name (group_col)是刚需 - 刷新要选对时机：用
REFRESH MATERIALIZED VIEW CONCURRENTLY（需唯一索引），否则锁表；但并发刷新不能在无主键/唯一约束的视图上跑 - 注意依赖关系：如果原表加了新分区或改了统计信息，物化视图不会自动感知，得手动
REFRESH
按时间字段分区后，COUNT/SUM 聚合为什么还是慢？
分区只是把数据物理拆开，不代表查询引擎会自动跳过无关分区——得靠约束排除（constraint exclusion）或更可靠的 partition pruning，而这高度依赖查询条件是否能被优化器识别。
使用场景：日志表按 created_at::DATE 分区，但写 WHERE created_at >= '2024-01-01' 却没走 pruning，原因常是类型隐式转换或函数包裹。
- 避免在分区键上用函数：写
WHERE DATE(created_at) = '2024-01-01'会禁用 pruning；应改用WHERE created_at >= '2024-01-01' AND created_at - 确保分区约束可推导：用
RANGE分区比LIST更利于范围裁剪；检查pg_partitioned_table和子表pg_constraint是否完整 - 小分区数量更稳：单个分区行数建议控制在千万级以内；分区太多（如按小时分 1000+ 个）反而增加规划器负担
物化视图 vs 分区表：该选哪个？
这不是二选一，而是“聚合结果要不要实时”决定的。物化视图存的是快照结果，分区表存的是原始数据——两者解决的问题根本不同。
性能影响：物化视图首次构建和刷新都可能阻塞写入，尤其大表；分区表对写入透明，但聚合查询仍需扫描多个子表，除非配合 BRIN 索引或分区剪枝。
- 要准实时聚合（比如看板每分钟刷新）：优先分区 + BRIN 索引 + 合理 WHERE 条件，避免物化视图刷新延迟
- 能接受 T+1 或小时级延迟（比如日报统计）：物化视图 + 定时
REFRESH更省资源，且聚合逻辑可复用 - 混合用也常见：用分区表存明细，另建轻量物化视图只聚合高频维度（如
SELECT date, region, SUM(sales) FROM fact_sales GROUP BY 1,2）
MySQL 或 ClickHouse 做同样聚合，思路有什么不同？
MySQL 没原生物化视图，也没原生分区剪枝优化（5.7+ 的 ALTER TABLE ... REORGANIZE PARTITION 很脆弱），硬上分区收益有限；ClickHouse 则相反——物化视图是核心能力，但它是“写时触发”，不是“查时缓存”。
容易踩的坑：CREATE MATERIALIZED VIEW 在 ClickHouse 里本质是监听源表写入并异步计算，如果源表用 ReplacingMergeTree，物化视图的更新顺序可能错乱。
- MySQL 替代方案：用事件调度器（
EVENT）定时跑聚合 INSERT INTO summary_table，配合INSERT ... ON DUPLICATE KEY UPDATE - ClickHouse 物化视图必须指定排序键：目标表引擎要是
ReplacingMergeTree或SummingMergeTree，否则重复写入会膨胀 - 别指望 ClickHouse 物化视图做复杂 JOIN：它只支持单表 SELECT，多表聚合得靠
JOIN引擎或预关联宽表
真正卡住聚合速度的，往往不是技术选型，而是 WHERE 条件能不能被下推、分区边界有没有对齐业务查询周期、以及物化视图的刷新粒度是否匹配下游消费节奏——这些细节一错，再好的机制也白搭。
