根本原因是DBLink不支持WHERE条件下推，导致全量拉取再本地过滤；用物化视图+FAST增量刷新可实现毫秒级查询，需建日志、覆盖列、显式指定REFRESH FAST，并启用QUERY REWRITE与统计信息更新。
跨库查询延迟高，根本原因不是网络或DBLink慢，而是每次查询都拉全量数据再本地过滤；用物化视图+增量刷新（FAST）能把它变成“本地查表”，延迟从分钟级降到毫秒级。
为什么DBLink直连查询总慢？
Oracle对SELECT * FROM t@dblink WHERE id = 123默认不把WHERE下推到远程库——它先把整张t表全量拉到本地，再在本地执行过滤。百万行数据走网络+本地内存处理，必然卡顿。
常见错误现象：
- 执行计划里出现
TABLE ACCESS FULL但没带@dblink后缀，说明过滤没下推 - 远程库CPU/IO不高，本地库
SQL*Net more data from dblink等待严重 - 加绑定变量后更慢（如
:id），因为下推逻辑对绑定变量更保守
真正可行的解法只有两个：要么用视图封装固定条件（如WHERE status = 'ACTIVE'），要么用物化视图把结果固化下来——后者支持增量、可索引、还能自动重写查询。
创建FAST刷新物化视图必须做的三件事
FAST刷新依赖物化视图日志，漏一步就退化成COMPLETE刷新（锁表+全量重建），完全失去低延迟意义。
实操建议：
- 在远程源表上建日志：
CREATE MATERIALIZED VIEW LOG ON t WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES;—— 必须含ROWID和SEQUENCE，否则FAST不生效 - 日志要覆盖物化视图查询中的所有列：如果
SELECT a, b, c FROM t@l，日志里就得有a、b、c，用ADD COLUMN补全 - 物化视图定义里显式写
REFRESH FAST ON DEMAND（或ON COMMIT），别依赖默认FORCE——FORCE遇到日志缺失会静默降级为COMPLETE
刷新作业卡住？先看调度器，不是SQL
物化视图刷新延迟高，80%以上不是DBMS_MVIEW.REFRESH本身慢，而是作业被压在队列里没跑。关键看dba_refresh和dba_jobs状态。
检查步骤：
- 查刷新组是否卡住：
SELECT NAME, LAST_REFRESH_DATE, STALENESS FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV';—— 如果STALENESS长期是STALE或UNUSABLE，且LAST_REFRESH_DATE几小时没更新，说明作业没触发 - 确认作业是否
BROKEN：SELECT WHAT, BROKEN, NEXT_DATE FROM DBA_JOBS WHERE WHAT LIKE '%dbms_mview.refresh%';——BROKEN = TRUE或NEXT_DATE远滞后，就是作业挂了 - 查并发槽位：
SHOW PARAMETER job_queue_processes;—— 值小于10时，多个MV共享刷新组必排队；Oracle 12c+务必迁移到DBMS_SCHEDULER，它支持资源组绑定，能抢到CPU优先级
查询没自动走物化视图？检查QUERY REWRITE开关
即使物化视图存在且刷新正常，应用发来的原始SQL也不会自动重写——除非你开了QUERY REWRITE且优化器判定它更优。
必须操作：
- 建物化视图时加
ENABLE QUERY REWRITE（默认是DISABLE）：CREATE MATERIALIZED VIEW mv_remote_t ENABLE QUERY REWRITE AS SELECT ...; - 确保用户有
QUERY REWRITE权限：GRANT QUERY REWRITE TO your_user; - 检查优化器是否启用重写：
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE;（或设为SYSTEM级参数） - 用
EXPLAIN PLAN FOR SELECT ...后查PLAN_TABLE，确认OBJECT_NAME字段显示的是物化视图名，不是基表名
容易被忽略的是统计信息：物化视图的统计信息不会随刷新自动更新，DBMS_STATS.GATHER_TABLE_STATS必须手动跑一次，否则优化器因成本估算失真而放弃重写。
