YashanDB|通过 DBLink 访问 Oracle 性能慢? 问题分析与优化指南!

在使用 YashanDB 执行带有 Oracle dblink 的 SQL 时，有用户反馈性能明显不如预期。本文结合实际案例，详细解析成因及优化思路，帮助大家在遇到类似问题时快速应对。

一、问题现象

在 YashanDB 中执行包含 Oracle dblink 表的 SQL，整体执行时间远高于直接在 Oracle 中通过 dblink 查询的耗时。

相同的数据量、相同的 SQL 逻辑;

Oracle 通过 dblink 查询远端 Oracle 数据，仅需不到 1 秒;

YashanDB 通过 dblink 查询远端 Oracle，同样 SQL，执行时间明显变长。

二、风险与影响

查询延迟明显增加，影响业务系统运行效率;

客户体验下降，尤其是对实时性要求高的业务场景。

三、影响范围

截止目前，所有版本的 YashanDB 都存在这一性能问题。

四、问题原因分析

深入排查后，发现主要原因有两点：

拉取了远端表的所有列

无论 SQL 只需要哪些字段，YashanDB 默认通过 dblink 把整个表的所有列都拉取回来;

导致网络传输量增大，无形中增加了延迟和资源开销。

单批次拉取数据量过小

默认 fetch size 设置过小(每批次只拉取 16 条记录);

在存在网络时延(如 0.4ms)的环境下，频繁的网络往返(RTT)放大了整体耗时。

相比之下，Oracle 在访问远端表时，仅拉回了查询中实际需要的列，同时合理控制了 fetch size，因此性能优势明显。

五、解决方法与规避建议

当前规避方式建议：

在远端 Oracle 创建视图，只包含需要查询的列;

本地查询时，不直接访问原表，而是通过视图访问，减少无效列的传输。

同时，从产品优化角度，YashanDB 后续内核优化方向包括：

只拉取 SQL 中涉及到的列数据;

动态调整 fetch size，提升批量拉取效率，降低网络延迟影响。

六、问题分析与测试过程

在模拟环境中，通过以下操作重现了现场问题：

使用 sudo tc qdisc add dev bond1 root netem delay 0.45ms 命令模拟 0.45ms 网络延迟;

将客户数据导入测试环境进行验证;

观察执行计划，确认 Oracle 只拉取了必要字段，而 YashanDB 则拉取了全表所有字段;

通过 OCI 编程示例测试不同 fetch size 下的性能，进一步验证优化方向。

结果发现：

只查询少量列 + fetch size 设置为 2000;

即使在有网络延迟情况下，访问远端表耗时也能控制在 100ms 左右。

七、经验总结

使用 dblink 访问远端数据时，减少不必要的列传输非常重要;

合理设置 fetch size，可以大幅降低网络延迟对性能的影响;

开发应用时，如有跨库访问需求，推荐设计轻量级视图，仅暴露必要字段。

通过这套分析与优化方法，可以显著提升 YashanDB 在 dblink 访问场景下的查询性能!