物化视图不适合每秒多次查询的聚合场景。因其刷新阻塞、不实时，CONCURRENTLY 仅缓解读阻塞但存在不一致风险；安全方案应采用预计算表+应用层增量维护或逻辑视图原子切换。
物化视图是否适合每秒多次查询的聚合场景
不适合。PostgreSQL 的物化视图本身不支持实时更新，REFRESH MATERIALIZED VIEW 是阻塞式全量重算操作，执行期间会持有 SHARE UPDATE EXCLUSIVE 锁，阻塞后续刷新和部分 DML；若在高频查询下频繁触发刷新，极易引发查询排队、锁等待甚至超时。真正需要毫秒级响应的聚合查询，应优先考虑普通视图 + 索引优化、或预计算表 + 应用层增量维护。
CONCURRENTLY 刷新能解决高并发查询冲突吗
能缓解但不彻底。使用 REFRESH MATERIALIZED VIEW CONCURRENTLY 可避免阻塞读查询（不锁全表），但它要求物化视图必须有唯一索引（通常是主键或 UNIQUE NOT NULL 列），且刷新过程仍需扫描基表并重建内部数据结构，CPU 和 I/O 开销不低。实际压测中，当刷新间隔短于 5 秒、基表日增百万行时，CONCURRENTLY 仍可能因索引维护延迟导致查询看到“过期中间态”——即新旧数据混杂的短暂不一致。
- 必须提前在物化视图上创建
UNIQUE索引，否则报错ERROR: cannot refresh materialized view "xxx" concurrently because it has no unique index - 刷新期间，新查询读到的是旧快照；刷新完成后才原子切换，但切换本身有微小窗口（通常
- 不能在事务块内执行
CONCURRENTLY，否则报错ERROR: REFRESH MATERIALIZED VIEW CONCURRENTLY cannot be executed from within a transaction block
如何用定时任务 + 原子切换模拟准实时刷新
绕开物化视图原生命令，改用两张表（agg_daily_stats_current 和 agg_daily_stats_next）+ 视图别名的方式实现无锁切换。核心是把耗时计算移出查询路径，用元数据切换代替数据搬运。
