划线反馈

NLJ/SPF batch rescan 问题汇总

更新时间：2026-05-14 09:21

适用版本：V3.2.x、V4.0.x、V4.1.x、V4.2.x内容类型：Troubleshoot

稳定性问题

快速分析 Batch Rescan 相关问题

当遇到业务问题时分析判断可能与 batch rescan 相关时，可以先按照如下步骤进行简单初筛，判断是否是 NLJ/SPF batch rescan 相关问题。

观察出问题的 SQL 的执行计划。

如果出问题的 SQL 的执行计划里有 NESTED-LOOP JOIN 或者 SUBPLAN FILTER 算子，并且对应算子的 use_batch=true 。
执行命令 set global _nlj_batching_enabled = false，关闭 batch rescan 。

如果问题不再出现，大概率是 batch rescan 相关问题，可以先通过关闭这个开关的方式进行规避（分布式场景下会有一定的性能回退），请联系 OceanBase 数据库技术支持人员，进一步分析。
如果线上遇到的是 core 问题的话
1. 首先观察core的堆栈，是否包含NESTED-LOOP JOIN或者SUBPLAN FILTER算子相关的堆栈
2. 查找到 ob_nested_loop_join_op.cpp/ob_subplan_filter_op.cpp 对应的堆栈， p spec_->group_rescan_查看 batch 标记是否为 true；如果为 true，则说明走了 batch_rescan;
3. 为了便于研发同学进行分析，可以按照以下教程从 core dump 里获取执行计划
  1. 下载 gdb 脚本
  2. all.txt
    
    到分析 core 的机器上，并重命名为 all.gdb 。
  3. gdb 打开 core 文件，并 source all.gdb 。
  4. 跳到最顶层的 ob_operator.cpp 对应堆栈，执行 showoptree this；或者跳到 ob_execute_result.cpp，执行 showoptree static_engine_root_ 。
    
    即可获得下图所示完整的执行计划：

正确性问题

NLJ batch rescan，右支 tsc 子算子需要逆序排序，结果错误

关键诊断信息

执行计划里包含 NLJ 算子，NLJ 算子走 batch rescan (use_batch = true); NLJ 算子的右支包含 window function，并且右支算子底下的 table scan 算子进行逆序扫描（reverse 关键字）。

问题现象

当生成的执行计划包含 NLJ/SPF，并且走 batch rescan 优化时，如果走逆序排序的话，可能会导致查询结果错误；

问题原因

针对 batch rescan 的场景，table scan 在调存储层的扫描接口时，需要存储层优先保证单个 batch 内按照 group_id 的顺序进行排序(即按照 table scan 给定的 range 序进行输出)，相同的 group 内默认会按照正序进行输出；当用户指定为逆序（reverse）时，会出现结果错误。

问题的风险及影响

影响 OceanBase 数据库中 Oracle 租户和 MySQL 租户，会导致正确性问题，查询结果不对。

影响的版本

OceanBase 数据库企业版 V4.2.1 BP1（oceanbase-4.2.1.1-101000062023103122）及之前的版本、V4.1.0 BP4（oceanbase-4.1.0.2-104000032023092119）及之前的版本。

解决方法

升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP2（oceanbase-4.2.1.2-102010012023120119）及之后版本。

规避方式

关闭 NLJ BATCH 优化。

obclient> set global _nlj_batching_enabled=false;

上层算子短路导致的 batch rescan 触发 4377 报错

关键诊断信息

执行计划里包含 NLJ/SPF 算子，NLJ/SPF（SubPlan-Filter）算子走 batch rescan (use_batch = true); 走 batch 的 NLJ 或者 SPF 上层包含 semi/anti-join 或者 SPF 等带有短路语义的算子；在执行期间，如果上层算子发生短路（因为条件提前结束，导致不需要消耗右支算子的所有输出行），并且重新发起 rescan 时，会导致底层 table look_up 算子的迭代器发生错位，进而导致执行的结果不符合预期或者触发索引扫描的防御性报错。

问题现象

会导致查询的输出结果不符合预期或者触发一些非预期的 4377 报错，索引扫描行数和回表行数对不上；伴随如下日志报错。

[2023-10-07 18:01:57.997938] ERROR [SQL.ENG] check_lookup_row_cnt (ob_table_lookup_op.cpp:213) [989571][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=10] [dc=0] Fatal Error!!! Catch a defensive error!(ret=-4377, lo
okup_rowkey_cnt=9, lookup_row_cnt=8) BACKTRACE:0xfce48b0 0x58273bf 0x5976e33 0x5976a6f 0x59767d3 0x597a589 0xec422ba 0xebd6450 0x5614e19 0xd175ea5 0xd19d9b7 0xd19f4dc 0x5614e19 0xd1041bd 0xd19d8bd 0xd19f4dc 0x5
614e19 0xdf11134 0x5614e19 0xd19f70d 0xd19f5d4 0x5614e19 0x56aabad 0x5614e19 0x5614c94 0x5614a1e 0x561469c 0x562a61c 0x5623eac 0x5621450 0x5612ddf 0x560dc63 0x560b8ff 0x5609a7e 0xc022d81 0x5608c97 0xc020511 0x5
6048f6 0xc020a87 0xfbb95c3 0xfbb941f 0xfe5c29f

问题原因

上层算子对右支的 rescan 可能存在因短路导致到的 skip scan（跳过一些输出行），并且 global index lookup 的 batch rescan 不支持 skip scan，因此导致迭代器的位置对应错误，后续的数据迭代进入非预期的流程中，最终行数对应不上，触发 4377 检查报错。

问题的风险及影响

影响 OceanBase 数据库中 Oracle 租户和 MySQL 租户，会导致正确性问题，查询结果不对。

影响租户

影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。

影响的版本

OceanBase 数据库企业版 V3.2.3 GA（oceanbase-3.2.3.0-20220419）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本。

解决方法

升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP10 Hotfix3（oceanbase-3.2.3.3-110030012023101913）、V3.2.3 BP10 Hotfix4（oceanbase-3.2.3.3-110040022023110614）、V3.2.3 BP10 Hotfix5（oceanbase-3.2.3.3-110050012023112210）、V3.2.3 BP10 Hotfix6（oceanbase-3.2.3.3-110060012024011615）、V3.2.3 BP10 Hotfix7（oceanbase-3.2.3.3-110070012024012316）、V3.2.3 BP10 Hotfix8（oceanbase-3.2.3.3-110080012024022713）、V3.2.3 BP10 Hotfix9（oceanbase-3.2.3.3-110090012024041611）、V3.2.3 BP10 Hotfix10（oceanbase-3.2.3.3-110100012024042814）、V3.2.3 BP10 Hotfix11（oceanbase-3.2.3.3-110110032024052217）、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 BP11（oceanbase-3.2.3.3-111000032024070822）、V3.2.4 BP7（oceanbase-3.2.4.7-107000012023113010）、V4.2.1 BP1（oceanbase-4.2.1.1-101000062023103122）。

规避方式

关闭 NLJ BATCH 优化。

obclient> set global _nlj_batching_enabled=false;

batch nlj+except op 正交导致查询结果错误

关键诊断信息

执行计划里存在 NLJ， NLJ 走 batch rescan，并且 NLJ 算子的右支子计划存在 except 算子，或者用户 SQL 里存在 except 或者 minus 等用法。

问题现象

存在查询结果错误等正确性问题。

问题原因

走到 batch nlj+except op 正交逻辑上时，如果第一行数据在 except 的所有 child 中都同时不存在数据，则逻辑上两个迭代器都为空，但 except op 的特殊在于当第一个 child 的迭代器为空时，就不会再去迭代第二个 child，这里就对第二个迭代器产生了短路效应，因此第二个迭代器在第一次 group rescan 的时候并没有被真正初始化；当 NLJ 用第二行数据去 rescan 时，期望的是对 NLJ 的右支都进行切迭代器动作，由于 except 的第二个迭代器第一次 rescan 因为短路没有被初始化，所以切迭代器的流程中认为结果为空(实际上没有执行真正的 rescan 动作)，将 iter_end_ 标记为 true，所以不会有数据返回。

问题的风险及影响

影响 OceanBase 数据库中 Oracle 租户和 MySQL 租户，可能会带来正确性问题。

影响的版本

OceanBase 数据库企业版 V4.1.0 BP4（oceanbase-4.1.0.2-104000032023092119）及之前的版本、V4.2.1 BP1（oceanbase-4.2.1.1-101000062023103122）及之前的版本。

解决方法

升级至问题已修复版本。目前已修复的版本包括 V4.2.1 BP2（oceanbase-4.2.1.2-102010012023120119）版本。

规避方式

关闭 NLJ BATCH 优化。

obclient> set global _nlj_batching_enabled=false;

稳定性问题

SPF 算子 exec params 里包含 sub_query 导致的 core

关键诊断信息

执行计划里包含SPF算子，SPF算子走batch rescan，并且SPF算子的exec_params里包含sub_query;

问题现象

当用户 SQL 里包含 sub_query 并且生成上图特征的执行计划时，在运行过程中可能会 core 掉。

问题原因

exec_params 是 SPF 算子扫描右支需要提供的参数，在 rescan 右支前需要保证参数对应的数据已经准备好；当 exec_params 里包含 sub_query 时，在 rescan 右支子计划时，对应的 sub_query 可能还没有执行，因此其对应的参数数据不可访问，导致 core 掉。

问题的风险及影响

影响 OceanBase 数据库中 Oracle 租户和 MySQL 租户，会对业务系统的稳定性产生影响，可能会 core 掉。

影响的版本

OceanBase 数据库企业版 V4.1.0 BP4（oceanbase-4.1.0.2-104000032023092119）及之前的版本。

解决方法

升级到包含修复的版本；修复版本里默认关闭 SPF 的 batch Rescan。

规避方式

关闭 NLJ BATCH 优化。

obclient> set global _nlj_batching_enabled=false; ---一些场景下可能会有性能回退。

SPF 算子 Batch Rescan 没有 reset 内存导致的 core

关键诊断信息

执行计划里需要存在一个走 batch 的 SPF 算子，并且 SPF 算子的上层需要存在一个支持rescan 接口的算子（NLJ/SPF）等；此外，还需要打开向量化引擎（默认打开）。

问题现象

当用户业务中存在可能生成以上子计划的 SQL 时，可能导致内存写坏进而出现一些非预期的 core dump；有时 core 会通过包含SPF的 SQL 触发，也可能会因为内存写坏导致一些无关的 SQL 也会 core。

问题原因

SPF 算子在进行 batch rescan 时没有 reset 向量化缓存，导致内存写坏出现一些非预期的 core。

问题的风险及影响

影响 OceanBase 数据库中 Oracle 租户和 MySQL 租户，当用户 SQL 生成上图特征的执行计划时，在运行过程中可能会 core 掉；或者一些无关sql也会 core 掉。

影响的版本

OceanBase 数据库企业版 V4.1.0 BP4（oceanbase-4.1.0.2-104000032023092119）及之前的版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）版本。

解决方法

升级至问题已修复版本。目前已修复的版本包括 V4.2.1 BP1（oceanbase-4.2.1.1-101000062023103122）版本，在修复版本里通过 _enable_spf_batch_rescan 配置项默认关闭 SPF 的 batch rescan 来规避这个问题，并且对向量化缓存进行 reset。

规避方式

关闭 NLJ BATCH 优化。

obclient> set global _nlj_batching_enabled=false; ---一些场景下可能会有性能回退。

batch nlj + merge group by 算子 core 掉问题

关键诊断信息

生成的执行计划里包含 NLJ 算子，并且 NLJ 算子走 batch-rescan，NLJ 算子的右支子计划里包含 MERGE GROUP BY 等包含物化操作的算子时，并且 NLJ 算子的右支 TABLE SCAN 算子需要进行索引回表操作。

典型的 core 堆栈如下：

问题现象

当用户执行的 SQL 会生符合上述特征的子计划时，在执行的过程中有一定的概率会 core 掉。

问题原因

NLJ batch rescan 的过程中没有正确 reset 表达式的 datum 指针，导致执行过程中 core 掉。

问题的风险及影响

影响 OceanBase 数据库中 Oracle 租户和 MySQL 租户，当用户 SQL 生成上图特征的执行计划时，在运行过程中可能会 core 掉。

影响的版本

OceanBase 数据库企业版 V4.1.0 BP4（oceanbase-4.1.0.2-104000032023092119）及之前的版本、V4.2.1 BP2（oceanbase-4.2.1.2-102010012023120119）及之前版本。

解决方法

升级至问题已修复版本。目前已修复的版本包括 V4.2.1 BP3（oceanbase-4.2.1.3-103000052023122809）版本。

规避方式

关闭 NLJ BATCH 优化。

obclient> set global _nlj_batching_enabled=false; ---一些场景下可能会有性能回退。

OceanBase 数据库的 sql_id 和 plan_id 的稳定性介绍

GV$PLAN_CACHE_PLAN_STAT 表中 executions=0 的原因

OceanBase 数据库