物化视图是预计算并持久化结果的物理表，非自动加速器；其加速原理在于跳过JOIN与聚合，因创建时已执行完全部计算并落盘，后续查询仅扫描该表。
物化视图不是“自动加速器”，而是你主动把计算结果存下来、再手动或半自动同步更新的物理表——它只在查询模式稳定、基表变更不频繁、且你愿意承担存储和刷新开销的前提下，才真正比原始SQL快。
物化视图为什么能跳过JOIN和聚合？
因为它根本不是在查源表。创建时（CREATE MATERIALIZED VIEW）那条SQL就被完整执行了一次：所有JOIN、GROUP BY、SUM()、COUNT(DISTINCT)全算完了，结果直接落盘成一张新表。后续SELECT只是对这张表做普通扫描或索引查找，自然绕开了最耗时的执行计划生成与中间结果物化阶段。
常见误判点：
- 以为建完就“自动生效”——PostgreSQL 默认不启用查询重写，
EXPLAIN里看不到物化视图被选中，得先设SET enable_material = on - 物化视图定义里用了
date_trunc('day', created_at)，但查询写的是WHERE created_at >= '2024-03-01'，优化器无法推导语义等价，直接弃用 - 源表有索引，但物化视图本身没建索引——
WHERE month = '2024-03'照样全表扫描
PostgreSQL中REFRESH必须手动触发？
是的。REFRESH MATERIALIZED VIEW默认是全量重跑定义SQL+全量覆盖数据，不增量、不事务安全、不自动绑定DML。这意味着：
-
REFRESH CONCURRENTLY可避免锁表，但要求物化视图已有唯一索引（否则报错cannot refresh concurrently without a unique index） - 高频刷新（如每分钟）会导致IO和CPU尖峰，尤其当基表达千万行、物化视图含多层JOIN时
- 若业务能接受15分钟延迟，用
pg_cron定时刷新比监听触发更可控；若需准实时，应考虑用逻辑复制+自定义消费者，而非强依赖物化视图
ClickHouse物化视图为何看起来“自动”？
它的“自动”是写入时触发，本质是INSERT事件驱动的管道：物化视图背后实际是一张目标表 + 一个隐式INSERT SELECT触发器。每次往源表写数据，就会按定义逻辑实时写一份到物化视图表中。
但这也带来硬约束：
- 源表引擎必须支持
ReplacingMergeTree或CollapsingMergeTree等可去重引擎，否则重复数据会堆积 - 物化视图定义不能含
JOIN（语法报错），聚合字段必须出现在GROUP BY中，且SELECT里不能有子查询 - 一旦源表写入失败，物化视图不会回滚——它和源表不在同一事务内，数据一致性靠应用层兜底
最容易被忽略的一点：物化视图不是缓存，没有TTL机制。它不会因为“冷”而自动失效或淘汰；也不会因为“热”而自动预热。它就是一张表——建了就得管，刷了就得验，查了就得索引，错了就得溯源。你省下的每一秒查询时间，都对应着你多担的一分维护责任。
