OceanBase里怎么查分布式子计划的RPC执行数，是不是都差不多，感觉挺重要的吧

在OceanBase这种分布式数据库里，查分布式子计划的RPC执行数，确实是一个非常关键的操作，你说感觉挺重要的，这个感觉完全正确，它就像是给数据库做“体检”时，一个能直接反映内部协同工作效率的核心指标，这个数字能告诉你，为了完成你发出去的那条SQL，数据库内部各个机器之间“打了多少次电话”（也就是RPC调用）。

为什么这事儿这么重要？

想象一下，OceanBase是由很多台服务器（称为OBServer）组成的，当你执行一条涉及多表关联、或者数据分散在不同服务器上的SQL时，优化器会生成一个执行计划，如果这个计划是分布式的，就意味着它需要在一台机器上协调，然后让多台机器同时干活，最后把结果汇总起来，这些机器之间的通信,就是通过RPC完成的。

RPC执行数如果异常高,可能意味着：

1. 数据分布不理想： 关联的两个大表，数据分布方式不匹配，导致一台机器需要向几乎所有其他机器请求数据，而不是只和少数几台通信，这就好比开会时，主持人需要挨个给几百个人打电话，而不是拉一个小组群聊,效率自然低下。
2. 执行计划不够好： 优化器可能选择了一个看似节省本地计算，但引入了大量网络通信的计划，网络传输的速度远慢于内存计算,大量的RPC会成为性能的主要瓶颈。
3. 资源消耗大： 每一次RPC都消耗CPU、网络带宽资源，RPC数过多，会直接导致整个数据库集群的负载升高,可能影响其他业务的正常运行。

查看RPC执行数，是判断一条分布式SQL是否高效、是否存在优化空间的最直观手段之一，如果发现RPC次数远远超过集群的机器数量（比如10台机器的集群，RPC数却成百上千）,那几乎可以肯定执行计划有问题。

怎么查？主要靠执行计划。

在OceanBase里，你不需要直接去某个系统表里查一个叫“RPC执行数”的孤立指标，这个信息是附着在SQL的执行计划展示里的，常用的方法是使用 EXPLAIN 命令来查看SQL的详细执行计划。

根据OceanBase的官方文档（例如V4.x版本）说明，在执行计划中，会包含一个叫做“分布式执行计划”的展示部分，你需要重点关注计划中每个算子（可以理解为执行步骤）的rpc_exchange相关信息。

具体操作和查看要点如下：

1. 获取执行计划： 在你的SQL工具（如OBClient、ODC等）中，在要分析的SQL语句前加上 EXPLAIN 关键字，如果想看更详细的信息，可以使用 EXPLAIN BASIC， EXPLAIN OUTLINE， 或者 EXPLAIN EXTENDED。EXPLAIN BASIC 就能看到算子级别的信息。
2. 解读执行计划输出： 执行计划的输出是树状结构，你需要寻找代表分布式操作的算子，最常见的比如 EXCHANGE OUTER / INNER（用于数据重分布）、PX COORDINATOR（并行执行协调器）等,这些算子通常会驱动RPC的发生。
3. 寻找关键信息： 在算子的详细信息中，你会看到诸如 dop（并行度）、task（任务数）等属性。RPC的执行次数，通常与这些任务的分发和收集次数紧密相关。 一个并行扫描操作，如果dop是10，可能就意味着至少需要10次RPC来分发任务和收集结果,更复杂的多表关联可能会产生倍数级的RPC调用。

举个例子来理解：

假设你有一条双表关联的SQL,集群有3台机器。

• 理想情况： 优化器生成了一个“分区 Wise Join”的计划，即关联条件正好匹配两个表的数据分布，这样，每台机器都可以在本地完成自己分区数据的关联，只需要最后向协调节点发送一次结果，这种情况下，RPC次数会很少,基本等于机器数量。
• 不理想情况： 如果无法实现本地关联，优化器可能选择“重分布”其中一张表，将表A的数据根据关联键，重新打散发送到所有3台机器上，然后每台机器再和本地的表B数据进行关联，这个“重分布”的过程，就会产生大量的RPC（表A有多少个数据分区，就可能产生相应倍数的RPC）。

是不是都差不多？

绝对不是。 这正是需要监控和优化的原因，RPC执行数在不同SQL、不同数据分布、不同执行计划下差异会非常大，一个设计良好的SQL和索引，可能让RPC数降到最低，而一个不经意的SQL写法改变或数据量增长，可能导致RPC数激增,从而引发性能雪崩。

查看OceanBase分布式子计划的RPC执行数，核心方法是通过EXPLAIN命令分析执行计划，重点关注那些会引起数据网络传输的算子（如EXCHANGE）及其属性（如dop, task），这个数值是衡量分布式SQL性能的关键标尺，绝非“差不多”就行，而是越低越好，通过观察和优化它，可以有效地降低网络开销,提升整个数据库集群的稳定性和响应速度。