数据库链接（Database Link，简称DBLink）是Oracle提供的跨库访问机制，通过它可以像查本地表一样查询另一个数据库里的数据。用起来确实方便，但方便的代价往往就是性能：明明在远程库本地执行只要几秒的SQL，套上DBLink之后动辄十几分钟。要想真正解决问题，得先弄清楚DBLink的工作原理，再针对具体瓶颈逐个击破。
先搞清楚DBLink是怎么执行SQL的
当你在SQL里引用一个通过DBLink访问的远程表时，Oracle并不是把你写的SQL原样发到远端执行。优化器会先把SQL改写成一段带有数据库链接标识的语句，通过Oracle Net（底层走的是SQL*Net协议）发送给远程库。远程库解析并执行这段语句，把结果集按批次回传给本地库，本地库再根据连接方式与本地数据进行组合。
这里隐藏着几个关键的性能变量。第一是网络往返次数（Round Trips），如果执行计划选择在本地做嵌套循环，每获取一行本地数据就要访问一次远程表，网络延迟会被成倍放大。第二是数据传输量，远程表没有过滤条件时，整张表的数据都会被拉到本地。第三是远程对象的统计信息，本地库默认拿不到远端表的真实统计信息，优化器只能靠估算，很容易产生糟糕的执行计划。理解了这三点，后面的优化手段就都有了解释依据。
最常见的性能陷阱：循环访问远程库
一个典型的慢查询场景是这样的：本地表只有几千行，通过DBLink关联一张远程大表，执行计划走了嵌套循环，对本地每一行都发起一次对远程表的探测。假设每次网络往返需要5毫秒，5000行数据就是25秒起步，如果远程表还需要按索引回表，时间会进一步膨胀。这种情况下问题根本不在远程库本身，而在于访问模式。
解决办法是想办法让远程访问次数从N次降到1次。一种思路是把本地驱动表的数据先推到远端，让整个查询在远程库执行完再回传结果，这可以通过DRIVING_SITE提示实现：
SELECT /*+ DRIVING_SITE(r) */ l.order_id, r.product_name FROM local_orders l, remote_products@remote_db r WHERE l.product_id = r.product_id AND l.create_date >= TRUNC(SYSDATE) - 30;
加了DRIVING_SITE(r)之后，Oracle会把本地表数据序列化后发送到远程库，在远程库完成连接运算，只把最终结果传回来。当远程表体积大、本地表过滤后数据量小时，这个改写经常能带来数量级的提升。反过来，如果远程表过滤后很小而本地表很大，则保持默认在本地执行即可，两种场景要区分对待。
另一种做法是在本地先收集要查询的键值，用IN列表一次性把远程数据取回来，再在本地做内存中的关联。PL/SQL里配合批量收集（BULK COLLECT）效果更好，能有效控制上下文切换次数。
用物化视图把远程数据本地化
如果远程数据的变化频率不高，比如维表、字典表、每日更新的汇总数据，最彻底的优化方式是干脆不在查询时访问远程库，而是在本地建一张物化视图定期同步。查询压力全部落在本地，远程库只承担同步时的读取开销，两者互不干扰。
CREATE MATERIALIZED VIEW mv_remote_products
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
AS
SELECT product_id, product_name, category_id, update_time
FROM remote_products@remote_db;
-- 每天凌晨两点定时刷新
BEGIN
DBMS_REFRESH.MAKE(
name => 'MV_REFRESH_GROUP',
list => 'MV_REMOTE_PRODUCTS',
next_date => TRUNC(SYSDATE) + 1 + 2/24,
interval => 'SYSDATE + 1');
END;
/
物化视图支持完全刷新和快速刷新两种模式。快速刷新要求远程表上有物化视图日志，只传输增量变更，适合数据量大但变化少的场景；完全刷新实现简单但每次都要全量拉取，适合小表。选哪种模式，取决于数据量和变更比例的权衡。
需要注意物化视图会占用本地存储，并且存在数据延迟，业务上必须能接受查询结果不是实时的。对于实时性要求高的交易类查询，这条路走不通，还是得回到执行计划和访问模式优化的老路上来。
容易被忽略的细节参数
除了SQL层面的改写，还有一些环境层面的因素值得检查。首先是数组提取大小，DBLink回传结果集时每次批次传输的行数受ARRAYSIZE和数据库初始化参数影响。SQL*Plus里默认的ARRAYSIZE是15，调大到500甚至1000后，大结果集的传输时间会有明显改善。应用侧的JDBC连接也可以通过设置defaultRowPrefetch达到同样效果。
-- SQL*Plus中调整每次网络往返提取的行数 SET ARRAYSIZE 500 -- 查看当前会话通过网络访问远程库的统计信息 SELECT statistic_name, value FROM v$sesstat s, v$statname n WHERE s.statistic# = n.statistic# AND n.name LIKE '%roundtrip%';
其次，可以在DBLink定义中指定会话级别的参数，确保远程会话使用合理的排序区和优化器模式，避免远端走了不合适的执行计划：
CREATE DATABASE LINK remote_db
CONNECT TO app_user IDENTIFIED BY password
USING '(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=10.0.1.20)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=orcl)))';
最后别忘了监控。通过V$SESSION里的MODULE和等待事件，可以确认远程访问是否成为瓶颈，常见的SQL*Net message from dblink等待事件占比过高，就说明大量时间花在了网络往返上，此时优化的重点应该放在减少访问次数和传输量，而不是去调远程库的索引。
总结一套排查思路
遇到DBLink慢的问题，建议按固定顺序排查：先看等待事件，确认时间消耗在网络传输还是远端执行；再看执行计划，判断是嵌套循环导致的循环访问，还是远程表被全量拉取；然后根据数据特征选择手段，小表驱动大表用DRIVING_SITE推到远端执行，数据不要求实时就上物化视图本地化，大结果集回传则调整数组提取参数。多数情况下，把远程访问次数从多次压缩到一次，性能问题就解决了一大半。分布式查询的性能从来不是玄学，把网络往返和数据传输这两个核心变量控制住，剩下的就是常规的SQL调优功夫了。
Oracle DBLink数据库性能优化分布式查询修改时间：2026-09-16 02:22:35