refresh materialized view concurrently 仍会锁表，因其需对源表加 share update exclusive 锁以读取快照和建唯一索引；若源表存在长事务或无唯一约束，则刷新阻塞或报错。
CONCURRENTLY 刷新为什么还会锁表
因为 REFRESH MATERIALIZED VIEW CONCURRENTLY 只避免对物化视图本身加 ACCESS EXCLUSIVE 锁，但底层仍需对源表加 SHARE UPDATE EXCLUSIVE 锁（用于读取最新快照和构建唯一索引）。如果源表正被大事务长时间写入，或者有未提交的 UPDATE/DELETE，刷新就会卡在获取该锁的阶段。
- 典型现象：
pg_stat_activity中状态为active，wait_event_type = 'Lock'，wait_event = 'relation' - 触发时机不等于“立刻执行”：它会排队等源表锁释放，不是异步任务，也不走后台进程
- 如果源表没有主键或唯一约束，
CONCURRENTLY刷新直接报错：ERROR: could not create unique index—— 它依赖唯一索引做新旧数据比对
什么情况下必须用 CONCURRENTLY，什么情况反而不该用
用不用的关键不在“要不要阻塞”，而在“有没有稳定唯一键”和“能不能容忍短暂不一致”。
- 必须用：
SELECT密集、不能接受秒级不可用的报表场景；源表有主键或含UNIQUE NOT NULL的列组合 - 不该用：源表只有普通索引、无任何唯一性保证；或物化视图仅用于离线 ETL，且刷新频次低（此时用普通
REFRESH更快、更少资源开销） -
CONCURRENTLY实际比普通刷新慢 2–5 倍：它要扫描两次源表（一次取旧数据，一次取新数据），还要维护临时索引
如何安全安排刷新时机以减少锁冲突
核心是避开源表写高峰，并确保刷新事务自身不被长事务拖住。
- 不要在业务高峰期跑定时刷新，尤其避开凌晨批处理、日结事务窗口
- 刷新前先查：
SELECT pid, state, now() - backend_start, query FROM pg_stat_activity WHERE state = 'active' AND query ~* 'update|delete|insert' AND now() - backend_start > interval '30 seconds';—— 如果有超 30 秒的活跃写事务，建议延迟刷新 - 在事务块里调用时，务必把
REFRESH MATERIALIZED VIEW CONCURRENTLY放在最外层，不要包裹在其他 DML 后面，否则可能升级锁粒度 - PostgreSQL 15+ 支持
REFRESH MATERIALIZED VIEW CONCURRENTLY ... WITH NO DATA（只重建结构），但仅限调试，生产慎用
常见错误信息与对应修复动作
这些报错不是语法问题，而是数据或结构层面的硬约束被违反。
-
ERROR: cannot refresh materialized view "xxx" concurrently because it does not have a unique index→ 给物化视图加唯一索引：CREATE UNIQUE INDEX ON mv_name (id);（列必须 NOT NULL） -
ERROR: could not create unique index "xxx_idx": duplicate key value violates unique constraint→ 源表数据存在重复，CONCURRENTLY无法判断哪条是“最新”，需先清理源表或改用普通刷新 +TRUNCATE + INSERT -
ERROR: permission denied for table xxx→ 执行用户缺少对源表的SELECT权限，不只是物化视图本身
真正麻烦的是那些没报错但刷新后数据“看起来对、实际漏更新”的情况——比如源表有逻辑删除标记但没进唯一索引，或者时间戳精度不足导致新旧行无法区分。这类问题不会抛异常，只能靠定期校验行数和关键字段聚合值。
