物化视图自动刷新卡住写入主因是底层刷新操作持锁阻塞DML：Oracle默认atomic_refresh=TRUE引发事务级锁，PostgreSQL不加CONCURRENTLY则持ACCESS EXCLUSIVE锁，且两者刷新均需全量扫描基表，高并发下易触发超时。
自动刷新机制本身不“自动”，它依赖的底层刷新动作（如 REFRESH MATERIALIZED VIEW 或 DBMS_MVIEW.REFRESH）在执行时必然持有锁，而锁的类型和范围直接决定基表是否可写。所谓“写入超时”，本质是业务 DML 被锁阻塞后触发了客户端或数据库层的 timeout 设置。
Oracle 快速刷新为什么卡住 INSERT/UPDATE
快速刷新（FAST）不是无锁操作——它需要读取物化视图日志表（MLOG$_xxx），然后对基表做行级 MERGE。但问题出在日志表扫描阶段：
- 若
MLOG$_xxx缺少(snaptime$$, sequence$$)复合索引，Oracle 会全表扫描+磁盘排序，期间持基表上的 ROW SHARE 锁（RS），虽不阻塞 SELECT，但会与高并发 UPDATE 冲突 - 如果刷新事务里还涉及大分区的 GROUP BY 或 JOIN，执行计划可能引入 WINDOW SORT，进一步延长锁持有时间
-
ATOMIC_REFRESH => TRUE（默认）会让整个刷新包在一个事务里：TRUNCATE 不允许、UNDO 持续增长，一旦 undo 表空间紧张或事务超时，基表锁就拖得更久
PostgreSQL 的 CONCURRENTLY 并不豁免基表压力
加 CONCURRENTLY 只能避免物化视图自身被 ACCESS EXCLUSIVE 锁死，但基表完全不受保护：
- 刷新仍需完整执行原始
SELECT查询，所有 JOIN、FILTER、GROUP BY 都照常压在基表上，CPU 和 I/O 峰值与手动查一次毫无区别 - 如果基表正被另一个长事务修改（比如一个未提交的
UPDATE ... WHERE status = 'pending'），刷新查询可能因等待行锁而卡住，间接导致后续业务写入排队 - 没有“增量应用”逻辑：哪怕只改了一行源数据，PostgreSQL 仍要重跑全部子查询，基表扫描范围不变
MySQL 手动模拟物化视图时最容易忽略的锁点
MySQL 没有原生物化视图，靠 TRUNCATE + INSERT 或 INSERT ... ON DUPLICATE KEY UPDATE 实现，但锁行为差异极大：
-
TRUNCATE TABLE mv_table是 DDL，在 InnoDB 中会获取元数据锁（MDL），阻塞所有对该表的 DML，包括基表无关的其他操作（只要它们碰了同一张物化表） -
INSERT ... SELECT默认走语句级复制（SBR），若开启 binlog，整个 SELECT 过程中基表会被一致性读快照锁定，大表扫描时长直接影响写入延迟 - 用
ON DUPLICATE KEY UPDATE做增量更新时，若唯一键设计不合理（比如用created_at时间戳作冲突判断），可能引发间隙锁（GAP LOCK）蔓延，把本不该锁的基表记录也卷进来
真正危险的不是“刷新要不要锁”，而是默认配置下没人检查锁的粒度和持续时间。一个 REFRESH 耗时 8 秒，意味着这 8 秒内所有试图修改基表关键字段的业务 SQL，都在等同一个锁释放——超时阈值设成 5 秒，就注定失败。
