Nest Loop Join 场景查询内存膨胀问题

问题现象

Nestloop Join 计划查询运行过程中，租户内存占用膨胀。

关键诊断信息

触发条件

NLJ 计划，右表是分区表，并且不同分区 TableStore 中 MemTable + SSTable 数量有的 <=3，有的 >3。

事前巡检

以下条件全部满足：

1. Nest Loop Join 计划。

2. NLJ 右表是分区表，并且访问多个分区。

3. 通过 __all_virtual_memory_info 可以看到租户内存被查询相关的 mod（比如 ScanDASCtx）占用多。

4. 通过 __all_virtual_table_mgr 查看右表不同分区的 MemTable + SSTable 数量有的 <=3，有的 >3。

5. 进一步通过抓取内存分配堆栈可以看到分配是在存储层的 ObMultipleScanMerge 中。

事后诊断

事后只能通过 SQL 监控、查询计划来判断是否有满足上述条件的 SQL。

问题原因

NLJ rescan 右表分区表，rescan 切分区会重用存储层迭代器，如果前一个分区 MemTable + SSTable 个数 <=3 multiplemerge 会使用 singlerowsmerger 归并，后一个分区 >3， multiplemerge 会使用败者树，OceanBase 数据库 V3.2.3 版本中的逻辑是释放 merger 内存重分配，但 allocator 不支持释放，如果大量 rescan 来回切换上述分区会导致内存一直膨胀，直到 SQL 结束才会释放。

问题的风险及影响

租户内存占用膨胀。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版本 V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本。

解决方法

• 解决方法一：

  升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP10 Hotfix12（oceanbase-3.2.3.3-110120012024060510）、V3.2.3 BP10 Hotfix13（oceanbase-3.2.3.3-110130012024061819）、V3.2.3 BP10 Hotfix14（oceanbase-3.2.3.3-110140012024082010）、V3.2.3 BP10 Hotfix15（oceanbase-3.2.3.3-110150012024102111）、V3.2.3 BP10 Hotfix16（oceanbase-3.2.3.3-110160012025021315）、V3.2.3 BP10 Hotfix17（oceanbase-3.2.3.3-110170012025032112）、V3.2.3 BP10 Hotfix18（oceanbase-3.2.3.3-110180012025060316）、V3.2.3 BP10 Hotfix19（oceanbase-3.2.3.3-110190022025082615）、V3.2.3 BP10 Hotfix20（oceanbase-3.2.3.3-110200012025111317）、V3.2.3 BP11（oceanbase-3.2.3.3-111000032024070822）。

• 解决方法二：

  1. 通过执行时间长（一般是 slow query，选错 NLJ 计划执行时间比较长）、计划、内存占用多的堆栈等信息找到对应 SQL，取消 SQL。

  2. 后续如果能够调整到 hash join，可以绑定计划避免。

规避方式

无。