物化视图不适合每秒多次查询的聚合场景。因其刷新阻塞、不实时，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）+ 视图别名的方式实现无锁切换。核心是把耗时计算移出查询路径，用元数据切换代替数据搬运。
- 后台作业（如 cron 或 pg_cron）定期执行：先清空
agg_daily_stats_next，再INSERT INTO agg_daily_stats_next SELECT ... FROM events WHERE ts > last_refresh_ts，最后更新last_refresh_ts - 用
CREATE OR REPLACE VIEW agg_daily_stats AS TABLE agg_daily_stats_current定义逻辑视图 - 切换时仅执行两条语句：
ALTER TABLE agg_daily_stats_current RENAME TO agg_daily_stats_old+ALTER TABLE agg_daily_stats_next RENAME TO agg_daily_stats_current，全程毫秒级，无锁无阻塞 - 为防切换失败，可加简单校验：比如
COUNT(*)对比、或检查MAX(ts)是否连续
为什么 pg_cron + 物化视图自动刷新仍是危险操作
因为 pg_cron 任务调用 REFRESH MATERIALIZED VIEW 本质还是同步执行，无法控制刷新时长。一旦基表膨胀或统计信息滞后，单次刷新可能从 200ms 拖延到 8 秒以上，而 pg_cron 默认不提供超时熔断或失败重试隔离——结果就是多个定时任务堆积、连接池打满、监控指标突刺。更隐蔽的问题是：物化视图依赖的基表若发生大事务（如批量 DELETE），REFRESH 会等事务结束，进一步放大延迟不确定性。
真正可控的方案，始终要把“计算耗时”和“查询服务”物理隔离，而不是依赖数据库内置的“看起来自动”的机制。
