远程INSERT性能瓶颈在于数据传输路径和执行计划控制，关键在“在哪插”和“插多少”；需强制本地驱动、避免远程表参与计算、分批提交并注意DB Link配置与分区访问细节。
直接结论：远程INSERT性能瓶颈不在SQL写法本身，而在数据传输路径和执行计划控制。关键不是“怎么插”，而是“在哪插”和“插多少”。
为什么INSERT ... SELECT @dblink会慢得离谱？
常见现象是：本地表只有几万行，远程表有千万级，但执行INSERT INTO remote_table@dblink SELECT * FROM local_table时，耗时远超预期，甚至触发远程库的全表扫描或锁表。
根本原因在于Oracle默认把远程表当作“驱动表”——它会先拉取远程表元数据、估算代价，再决定执行计划。一旦远程表过大或缺少统计信息，优化器就倾向于在远程端做大量运算（比如JOIN、FILTER），导致海量数据跨网传输。
真正有效的做法是：让所有计算发生在本地，只把最终结果集发过去。
- 确保
SELECT子句中不包含远程表的列（除非必要），避免隐式远程访问 - 用
/*+ driving_site(local_table) */强制本地为驱动端，尤其当local_table是小表时 - 禁用远程端自动收集统计信息干扰（如远程表刚被TRUNCATE过，统计信息陈旧）
APPEND + NOLOGGING能用吗？
不能直接用。因为/*+ append */是直接路径插入，在远程表上生效的前提是：你拥有远程库的INSERT /*+ append */权限，且远程表处于NOLIMIT或NOLIMITED状态（实际需远程DBA确认）。更常见的情况是：本地发出的INSERT /*+ append */提示，在远程端被忽略，退化为常规INSERT。
稳妥做法是分两步：
- 先在远程库执行
ALTER TABLE remote_table NOLOGGING（需DBA授权） - 本地INSERT语句显式加上
/*+ append */，并确认远程执行计划中出现LOAD AS SELECT而非INSERT STATEMENT - 事后记得切回
LOGGING，否则影响备份与恢复
如何避免事务过大和网络中断失败？
一次性插100万行，失败就得重来；网络抖动一次，整个事务回滚。这不是理论风险，是真实生产事故高频点。
必须分批，但不是简单用ROWNUM ——那会导致每次都要重新全扫<code>local_table。
- 按主键/时间字段分片，例如
WHERE id BETWEEN 1 AND 10000，并确保该字段有索引 - 用
COMMIT隔开每批，但别太频繁（如每5000行commit一次），否则日志写放大严重 - 加异常捕获逻辑，记录已处理的最大ID，断点续传才可行
- 远程端开启
DB_LINK_TIMEOUT参数（如设为600秒），避免连接挂起阻塞后续批次
真正容易被忽略的细节
DB Link创建时用的是PUBLIC还是私有？如果是PUBLIC，所有用户共享同一连接池，某人一个慢查询会拖垮所有人；而私有DB Link虽隔离，但每个会话新建连接，可能触发远程库的连接数限制。
还有：远程库是否启用了RESULT_CACHE？如果远程表上有频繁查询的视图，没关掉它，INSERT可能被缓存机制意外阻塞。
最隐蔽的一点：@dblink_name后跟的表名，如果远程表是分区表，而本地SQL没指定具体分区，Oracle可能跨所有分区扫描——哪怕你只INSERT一行。
