物化视图同步延迟主因是刷新机制与数据变更节奏错配，90%以上源于日志缺失、作业卡死或标记设计错位；Oracle FAST刷新静默降级为COMPLETE、PostgreSQL并发刷新缺唯一索引、MySQL增量同步依赖单一时间戳均会导致严重延迟。
物化视图同步延迟严重，基本不是“刷新慢”本身的问题，而是刷新机制没对上数据变更节奏——日志缺失、作业卡死、标记设计错位，三者占了90%以上原因。
Oracle FAST刷新失败却静默降级为COMPLETE
这是最隐蔽的性能杀手：你写了REFRESH FAST ON DEMAND，但执行计划里查DBA_MVIEWS发现STALENESS是UNUSABLE或STALE，且LAST_REFRESH_DATE长期不更新。根本原因是物化视图日志不满足FAST条件。
- 必须在源表上建日志：
CREATE MATERIALIZED VIEW LOG ON t WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES——漏掉ROWID或SEQUENCE，FAST直接失效 - 日志字段要覆盖查询中所有列：比如物化视图
SELECT a, b, c FROM t@dblink，日志就得含a、b、c；用ADD COLUMN补，别重建成日志 -
REFRESH FORCE会静默退化为COMPLETE（全量重建+锁表），务必显式写REFRESH FAST
PostgreSQL CONCURRENTLY刷新报错“no unique index”
想无锁刷新却卡在ERROR: cannot refresh materialized view "xxx" concurrently because it does not have a unique index，说明物化视图缺少支撑并发更新的索引基础。
- 必须先建唯一索引，且字段要覆盖所有JOIN键和业务主键，例如：
CREATE UNIQUE INDEX idx_mv_orders_user ON mv_orders_user (order_id, user_id) - 索引不能只建在单列上——如果物化视图含
GROUP BY a, b，索引就得是(a, b)或前缀能匹配查询谓词 -
REFRESH MATERIALIZED VIEW CONCURRENTLY不能放在事务块里（BEGIN; ... COMMIT;），否则报错
MySQL“模拟物化视图”同步时反复拉取或漏数据
用REPLACE INTO ... SELECT + 时间戳增量同步，结果MAX(updated_at)查出来是空，或者同一秒内多条记录被跳过——时间字段本身不具备唯一性，单靠它做游标必然出错。
- 必须用双重判据：
WHERE update_time > ? OR (update_time = ? AND id > ?)，同步任务本地保存两个值：last_time和last_id - 源表
updated_at字段必须由所有写入路径强制更新（包括INSERT），否则新插入行可能被跳过 - 批量大小建议1000–5000行/批；加
FOR UPDATE SKIP LOCKED（MySQL 8.0+）防多实例重复消费
刷新作业在队列里排队不动
查DBA_JOBS发现BROKEN = TRUE，或NEXT_DATE比当前时间早几小时，说明调度器根本没触发刷新——不是SQL慢，是作业压根没跑。
- 检查
job_queue_processes参数：SHOW PARAMETER job_queue_processes，值小于10时，多个MV共享刷新组必排队 - 确认作业是否
BROKEN：SELECT WHAT, BROKEN, NEXT_DATE FROM DBA_JOBS WHERE WHAT LIKE '%dbms_mview.refresh%' - 别依赖
ON COMMIT自动刷新——高并发写入下易冲突，改用ON DEMAND配合外部调度（如DBMS_SCHEDULER）更可控
真正难调的从来不是语法，而是增量标记与刷新节奏的咬合：Oracle看日志字段是否全覆盖，PostgreSQL看唯一索引是否真能区分每一行，MySQL看时间+主键是否构成严格单调游标——漏掉任一环，延迟就从秒级滑向分钟级。
