物化视图刷新时通常会锁表，postgresql默认全量刷新阻塞查询，加concurrently可避免但有限制；oracle on commit拖慢写入，on demand手动刷新仍可能锁段；mysql无原生物化视图，替代方案无锁但数据过期。
物化视图刷新时会锁表吗？
取决于数据库实现，但绝大多数场景下——会，而且是强一致性代价的根源。
- PostgreSQL 的
REFRESH MATERIALIZED VIEW默认执行全量重算+原子替换，期间新查询会阻塞，直到刷新完成；加CONCURRENTLY可避免锁，但要求有唯一索引且不支持全量重刷（只能做增量差分） - Oracle 的
ON COMMIT物化视图在事务提交时触发刷新，若基表更新频繁，可能拖慢写入；ON DEMAND则由 DBA 控制，但手动调用DBMS_MVIEW.REFRESH时仍可能锁住 MV 对应的 segment - MySQL 不原生支持物化视图，常见替代方案（如用普通表 + 定时
INSERT ... SELECT）完全无锁，但查询时可能读到过期数据——这是用一致性换并发
普通视图查得慢，换成物化视图就一定快？
不一定。物化视图只是把计算成本从查询时挪到了刷新时，还可能引入新瓶颈。
- 如果基表很小、查询逻辑简单（比如只含
WHERE id = ?），普通视图直接走索引，反而比物化视图更轻量 - 物化视图的存储本身要占空间，且每次刷新都触发 I/O 和 CPU 计算；若每天只查 1 次，而每小时刷 1 次，纯属浪费
- 某些数据库（如 ClickHouse）对普通视图做了下推优化，能将
WHERE条件下推到基表扫描层，而物化视图一旦建好，过滤逻辑就固化了，灵活性下降
查询一致性：为什么刚刷新完的物化视图，SELECT 还能看到旧数据？
不是刷新失败，而是事务隔离级别或刷新机制导致的“可见性延迟”。
- PostgreSQL 中，
REFRESH MATERIALIZED VIEW CONCURRENTLY是通过创建新版本 + 交换指针实现，但当前正在运行的事务（开启于刷新前）仍看到旧快照，这是 MVCC 的正常行为 - Oracle 如果用
ATOMIC_REFRESH => FALSE，会先TRUNCATE再INSERT，此时其他会话可能查到空表——这不是数据丢失，而是刷新过程不可见 - 避免该问题的关键不是禁用并发刷新，而是让应用层接受“最终一致性”，或在关键路径上显式加
SELECT ... FOR UPDATE等同步手段（但会牺牲并发）
SQL Server 的 indexed view 和物化视图是一回事吗？
功能接近，但底层机制和约束完全不同，不能直接类比。
- SQL Server 的 indexed view 实质是带唯一聚集索引的视图，数据物理存在，但**不自动刷新**——它依赖基表的 DML 触发器隐式维护，所以写入开销大，且必须满足一堆苛刻条件（如
SCHEMABINDING、确定性函数、不允许GETDATE()等） - 它没有“刷新命令”，也没有“刷新时间点”的概念；一旦建错，DML 可能直接报错
Cannot schema bind view或Index cannot be created - 真正等价于传统物化视图的是 SQL Server 2022+ 的
MATERIALIZED VIEW（预览特性），需显式启用并调用ALTER MATERIALIZED VIEW ... REFRESH
