有网络传输为何还会生成本地计划？

问题解答

计划中如果有 DISTRIBUTED TABLE SCAN 算子，虽然是本地计划，但是实际也有数据的网络传输。

问题举例

环境信息：三 Zone 三副本，各个副本的 Leader 打散在三个分区上。

表定义：一张三十个分区的分区表，上面有三个索引，一个没有分区的 global index，两个和主表一样有三十个分区的 local index 。

因为 SQL 涉及的表是分区表，各个分区的主副本都被打散在了不同的 Zone 里，并且 SQL 的过滤条件又不包含分区键，所以 proxy 这个时候是没办法知道要怎么对这条 SQL 进行路由的。这时候 proxy 就会随机路由到任意一台节点上，如下图所示。

但是收集完统计信息之后，发现可以稳定选择走 unique_did_uuid 这个 global index，计划如下所示：

看上去没有 remote xxx 算子和 exchange xxx 算子，不是远程计划和分布式计划，那么这就是个本地计划。

这个计划虽然是本地计划，但是实际也有数据的网络传输。因为 SQL 需要根据 update_time 列进行排序，global index 中并没有这个列的数据，所以过滤完之后，肯定还需要回主表（计划里也可以看到 is_index_back = true）去拿 update_time 列的值，一定还是会走网络的。

不过这个本地计划里的网络传输，和上一个计划有明确的 exchange 算子表示网络传输有所不同，这个计划里的网络传输被封到了一号算子里。一号算子是 DISTRIBUTED TABLE SCAN，含义是 TABLE SCAN 走了 DAS 执行。可以简单地将 DAS 理解成是一种特殊场景下，对网络传输的优化。

DAS 不需要像 remote 或者 exchange 算子一样在网络中把复杂的 SQL 或者子计划在节点间传来传去，而是直接跟存储层交互，通过 RPC 拉取到存储层的数据。

DAS 一般会出现在简单的点查，或者全局索引回表中。DAS 可以通过特殊的 RPC 和存储层直接进行远程数据的交互，所以可以减少在网络里传输 SQL 和子计划的开销。在这两种场景下，通过 DAS 的方式进行数据的网络传输，资源消耗是最小的，如下图所示。

有关 DAS 执行的介绍参见 DAS（data access service）简介 。

• 如果以 proxy 转发 SQL 到 Zone2 这台 OBServer 上为例，那么 Zone2 上这台 OBServer 就会通过 DAS 发 RPC 拉取另外几个节点上的主表数据，进行全局索引回表，如下图所示。

  

• 如果以 proxy 转发 SQL 到 Zone1 这台 OBServer 上为例，那么 Zone1 上这台 OBServer 首先会通过 DAS 发 RPC 直接拉取 Zone2 上 global index 主副本上的经过过滤之后的数据（过滤条件也一起下压过去了），然后再通过 DAS 发 RPC 拉取另外几个节点上的主表数据，进行全局索引回表，如下图所示。

  

所以无论 proxy 把 SQL 路由到哪个节点，这条 SQL 中网络传输的动作，都被封到一号 DISTRIBUTED TABLE SCAN 算子里了（一号算子通过 DAS 执行完成了全部的网络传输），因此可以生成稳定的计划。

适用版本

OceanBase 数据库 V3.2.x 及之后版本。