问题现象
问题的现象是生成如下的计划时，5 号 NESTED LOOP JOIN 输出的结果比预期少，甚至可能是空集。
这个计划中只需要关注红框标注的这部分，这部分是一个 partition-wise 计划，A 表和 B 表都是分区表，连接键是分区键，A 和 B 对应的一对分区被分配给同一个线程，执行 JOIN 操作。
问题现象是 JOIN 输出的结果比预期少，一对分区的匹配结果要么都被输出，要么都没有被输出。
出现问题的条件：
生成类似上面的计划，GI 算子 partition wise join 算子下面，生成了两个 Granule Iterator 算子，而不是上提到 JOIN 上面生成一个 GI 算子。
两表的分区方式不完全相同。两表分区方式不完全相同时通常做不了 partition-wise join，但是如果分区裁剪后分区方式相同，比如 A 表 10 个 range，B 表 5 个range，裁剪后都剩两个 range 并且 range 相同，那么就可以做 partition-wise join。
关键诊断信息
触发条件
A 表和 B 表都是分区表，连接键是分区键，A 和 B 对应的一对分区被分配给同一个线程，执行 JOIN 操作。
问题原因
原因是 GI 算子切分任务时，把一张表裁剪后的分区随机排序，然后等分给每个线程，在 partition wise 计划中，如果两个 GI 算子随机排序的方式不同，会导致对应的一对分区被分配个不同的线程，从而无法生成正确的匹配结果。
随机排序的方式是用 partition_idx 计算 hash 值，然后按 hash 值排序。当分区方式不同时，两张表中对应的一对分区的 partition_idx 是不同的。
问题的风险及影响
可能导致输出错误结果，预期结果集不为空，实际为空。
影响租户
影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。
影响版本
OceanBase 数据库企业版 V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本。
解决方法
解决方法： 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP9（oceanbase-3.2.3.3-109000182023071410）、V3.2.4 BP6（oceanbase-3.2.4.6-106000062023110109）、V4.1.0 BP3（oceanbase-4.1.0.2-103000072023081111）。
应急办法： 调整并行度为 1，这样所有分区都划分给一个线程。 或者调整 schema 让两表的分区方式相同。
