同步刷新机制并非数仓通用标配，仅限Oracle、PostgreSQL 15+等少数系统支持；Snowflake、BigQuery、Redshift等主流平台均不提供真正同步刷新，多依赖异步或近实时模拟。
同步刷新机制（synchronous refresh）在高级数据仓库中不是通用标配，它只在极少数支持强一致性物化视图的系统里存在，比如某些配置下的 materialized view（如 oracle、postgresql 15+ 的 refresh materialized view concurrently），但绝大多数现代数仓（snowflake、bigquery、redshift）根本不提供真正意义上的同步刷新——它们要么异步，要么靠微批/流式任务模拟“近实时”，强行套用这个概念反而会导致任务卡死或锁表。
为什么 REFRESH MATERIALIZED VIEW 默认是阻塞的
物化视图刷新本质是一次全量或增量重计算 + 数据替换。默认行为（如 PostgreSQL 的 REFRESH MATERIALIZED VIEW）会加 SHARE UPDATE EXCLUSIVE 锁，阻塞写入和后续刷新请求。这不是设计缺陷，而是为了保证查询时看到的数据版本一致。
- 如果你在 OLTP 场景下频繁调用，
SELECT查询可能被挂起数秒甚至更久 - Oracle 的
ON COMMIT刷新看似“同步”，实则把刷新延迟到事务提交时，且仅支持简单查询定义，稍复杂就报ORA-12052 - BigQuery 的
CREATE MATERIALIZED VIEW完全不支持手动刷新命令，刷新由系统自动触发，你无法控制时机
CONCURRENTLY 刷新能解决什么，又带来什么限制
PostgreSQL 9.4+ 提供 REFRESH MATERIALIZED VIEW CONCURRENTLY，它通过构建新版本 + 原子切换避免长时间锁表，但代价是：必须提前建好唯一索引，且不支持含 GROUP BY 或窗口函数的物化视图。
- 执行前必须确保物化视图已有唯一索引，否则报错：
ERROR: cannot refresh materialized view "mv_foo" concurrently because it has no unique index - 刷新期间允许读，但新旧版本之间可能有几秒不一致（最终一致性），不适合银行对账类强一致场景
- 不能在事务块内使用
CONCURRENTLY，否则报ERROR: REFRESH MATERIALIZED VIEW CONCURRENTLY cannot be executed from within a transaction block
当真需要“同步感”，该用什么替代方案
与其纠结“同步刷新”，不如按实际 SLA 拆解需求：是要求查询结果延迟
- 若需亚秒级更新：用流式处理（如 Flink + Kafka → Iceberg 表的
UPSERT）替代物化视图，查的是最新分区，非刷新逻辑 - 若怕锁表影响业务：把物化视图拆成两张表（
mv_active/mv_staging），用ALTER TABLE ... RENAME TO原子切换，自己控制刷新周期 - 若依赖强一致聚合结果：放弃物化视图，改用实时计算引擎（Doris、StarRocks）的物化视图自动异步刷新 + 查询路由，它们内部做了版本隔离，用户无感
真正麻烦的从来不是“怎么调一个同步刷新参数”，而是没想清楚：你到底要一致性的语义，还是低延迟的感知，抑或只是想绕过调度系统手工触发一次更新。选错方向，再“同步”的命令也救不了数据口径漂移和查询抖动。
