OceanBase的SQL 优化实践： NOT IN 子查询

作者：胡呈清，爱可生 DBA 团队成员，擅于故障分析、性能优化。

数据库版本：OceanBase V3.2.3

本文借助一个案例，来了解 not in 对 NULL 值敏感的处理逻辑，并探讨相应的优化方法。

问题概要

前不久，我遇到了一个慢SQL的case，在这段SQL中，原本的NOT IN子查询被优化器改写成了NESTED-LOOP ANTI JOIN，然而，由于被驱动表的全表扫描无法用索引，导致执行耗时达16秒。具体的SQL语句如下：

SELECT AGENT_ID, MAX(REL_AGENT_ID)FROM T_LDIM_AGENT_UPRELWHERE AGENT_ID NOT IN (select AGENT_IDfrom T_LDIM_AGENT_UPRELwhere valid_flg = '1')group by AGENT_ID;

简略执行计划如下：

==============================================================================================
|ID|OPERATOR              |NAME                                           |EST. ROWS|COST    |
----------------------------------------------------------------------------------------------
|0 |MERGE GROUP BY        |                                               |146      |62970523|
|1 | NESTED-LOOP ANTI JOIN|                                               |149      |62970511|
|2 |  TABLE SCAN          |T_LDIM_AGENT_UPREL(I_LDIM_AGENT_UPREL_AGENT_ID)|27760    |10738   |
|3 |  MATERIAL            |                                               |13880    |11313   |
|4 |   SUBPLAN SCAN       |VIEW1                                          |13880    |11115   |
|5 |    TABLE SCAN        |T_LDIM_AGENT_UPREL                             |13880    |10906   |
==============================================================================================

问题分析

1. 分析表结构、数据量

表结构如下，关联字段 AGENT_ID 是有索引的：

CREATE TABLE "T_LDIM_AGENT_UPREL" ("REL_AGENT_ID" NUMBER(22) CONSTRAINT "T_LDIM_AGENT_UPREL_OBNOTNULL_1679987669730612" NOT NULL ENABLE,"AGENT_ID" NUMBER(22),"EMPLOYEE_ID" NUMBER(22),"EMP_PARTY_FULLNAME" VARCHAR2(60),"GRP_ID" NUMBER(22),"GRP_PARTY_FULLNAME" VARCHAR2(255),"CS_ID" NUMBER(22),"CS_ORGAN_NAME" VARCHAR2(255),"CRT_DTTM" DATE,"LASTUPT_DTTM" DATE,"VALID_FLG" VARCHAR2(1),"VALID_DTTM" DATE,"INVALID_DTTM" DATE,CONSTRAINT "PK_T_LDIM_AGENT_UPREL" PRIMARY KEY ("REL_AGENT_ID")
);
CREATE INDEX "IDX_T_LDIM_AGENT_UPREL_CT" on "T_LDIM_AGENT_UPREL" ("CRT_DTTM") GLOBAL ;
CREATE INDEX "IDX_T_LDIM_AGENT_UPREL_LT" on "T_LDIM_AGENT_UPREL" ("LASTUPT_DTTM") GLOBAL ;
CREATE INDEX "I_LDIM_AGENT_UPREL_AGENT_ID" on "T_LDIM_AGENT_UPREL" ("AGENT_ID") GLOBAL ;

数据量：T_LDIM_AGENT_UPREL 表一共 2.7 万行，子查询结果 3900 行。

2. 判断直接原因

从执行计划、表结构和数据量来看，这个 SQL 效率低有两个原因：

关联字段 AGENT_ID 有索引，但对被驱动表做查询时却使用全表扫描，效率必定低。为什么不走索引？
既然被驱动表不走索引，基于代价的比较，优化器为什么没有选择更高效的 HASH ANTI JOIN？

问题得一个一个看，先分析第二个问题。

3. 使用 HINT 干预 JOIN 算法

使用如下 HINT 都不生效（并且尝试了 Outline Data 中的写法）：

/*+ use_hash(A B)*/ 
/*+ USE_HASH(@"SEL$1" ("VIEW1"@"SEL$1" )) */
/*+ NO_USE_NL_AGGREGATION */

执行计划显示 Used Hint 部分都为空，说明 HINT 无法生效，原因未知：

Used Hint:
-------------------------------------/*+*/Outline Data:
-------------------------------------/*+BEGIN_OUTLINE_DATANO_USE_HASH_AGGREGATION(@"SEL$1")LEADING(@"SEL$1" ("REPORT.A"@"SEL$1" "VIEW1"@"SEL$1" ))USE_NL(@"SEL$1" ("VIEW1"@"SEL$1" ))PQ_DISTRIBUTE(@"SEL$1" ("VIEW1"@"SEL$1" ) LOCAL LOCAL)USE_NL_MATERIALIZATION(@"SEL$1" ("VIEW1"@"SEL$1" ))INDEX(@"SEL$1" "REPORT.A"@"SEL$1" "I_LDIM_AGENT_UPREL_AGENT_ID")FULL(@"SEL$2" "REPORT.B"@"SEL$2")END_OUTLINE_DATA*/

4. 对比 Oracle 执行计划

Tips：当 OB 上看到的执行计划不符合预期，但又找不到原因时，可以对比 Oracle 的执行计划。

Oracle 上执行计划如下（这里得用 set autotrace on 的方式查看真实执行计划）：

可以使用 HASH ANTI JOIN，并且有个重要信息 HASH JOIN RIGHT ANTI NA （EXPLAIN 是看不到 NA 的），

直接搜索就可以得到大概的解释 NA 即 Null-Aware Anti Join，这种反连接能够处理 NULL 值。啥意思？下面展开讲讲。

SQL> set autotrace on
SQL> SELECT AGENT_ID, MAX(REL_AGENT_ID)FROM T_LDIM_AGENT_UPRELWHERE AGENT_ID NOT IN (select AGENT_IDfrom T_LDIM_AGENT_UPRELwhere valid_flg = '1')group by AGENT_ID;  2    3    4    5    6  no rows selectedExecution Plan
----------------------------------------------------------
Plan hash value: 1033962367
-----------------------------------------------------------------------------------------------
| Id  | Operation                | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |                    |     9 |   171 |   276   (2)| 00:00:04 |
|   1 |  HASH GROUP BY           |                    |     9 |   171 |   276   (2)| 00:00:04 |
|*  2 |   HASH JOIN RIGHT ANTI NA|                    |  9672 |   179K|   275   (2)| 00:00:04 |
|*  3 |    TABLE ACCESS FULL     | T_LDIM_AGENT_UPREL |  3886 | 31088 |   137   (1)| 00:00:02 |
|   4 |    TABLE ACCESS FULL     | T_LDIM_AGENT_UPREL | 28098 |   301K|   137   (1)| 00:00:02 |
-----------------------------------------------------------------------------------------------Predicate Information (identified by operation id):
---------------------------------------------------2 - access("AGENT_ID"="AGENT_ID")3 - filter("VALID_FLG"='1')

5. NULL 值与 NOT IN

为了更好的说明 NULL 值对 NOT IN 的影响，下面举个简单的例子：

create table t1(a number,b varchar2(50),c varchar2(50) not null);
insert into t1 values(1,'aaa','aaa'),(2,'bbb','bbb'),(3,'ccc','ccc'),(4,NULL,'ddd');
commit;

只要 NOT IN 后面的子查询或者常量集合一旦有 NULL 值出现，则整个 SQL 的执行结果就会为 NULL：

obclient [TESTUSER]> select * from t1 where b not in('aaa',NULL);
Empty set (0.004 sec)obclient [TESTUSER]> select tt.b from t1 tt where tt.a=4;
+------+
| B    |
+------+
| NULL |
+------+
1 row in set (0.007 sec)obclient [TESTUSER]> select t.* from t1 t where b not in(select tt.b from t1 tt where tt.a=4);
Empty set (0.005 sec)

NOT EXISTS 对 NULL 值不敏感，这意味着 NULL 值对 NOT EXISTS 的执行结果不会有什么影响：

obclient [TESTUSER]> select t.* from t1 t where not EXISTS (select tt.b from t1 tt where t.b=tt.b and tt.a=4);
+------+------+-----+
| A    | B    | C   |
+------+------+-----+
|    1 | aaa  | aaa |
|    2 | bbb  | bbb |
|    3 | ccc  | ccc |
|    4 | NULL | ddd |
+------+------+-----+
4 rows in set (0.005 sec)

IN 对 NULL 值也不敏感：

obclient [TESTUSER]> select * from t1 where b in('aaa',NULL);
+------+------+-----+
| A    | B    | C   |
+------+------+-----+
|    1 | aaa  | aaa |
+------+------+-----+
1 row in set (0.004 sec)obclient [TESTUSER]> select t.* from t1 t where b in(select tt.b from t1 tt where tt.a<5);
+------+------+-----+
| A    | B    | C   |
+------+------+-----+
|    1 | aaa  | aaa |
|    2 | bbb  | bbb |
|    3 | ccc  | ccc |
+------+------+-----+
3 rows in set (0.002 sec)

结合 Null-Aware Anti Join，我们可以得到如下结论：

NOT IN 和 <>ALL 对 NULL 值敏感，这意味着 NOT IN 后面的子查询或者常量集合一旦有 NULL 值出现，则整个 SQL 的执行结果就会为 NULL。

所以一旦相关的连接列上出现了 NULL 值（实际只会判断字段是否有 NOT NULL 约束），此时 Oracle 如果还按照通常的 ANTI JOIN 的处理逻辑来处理（实际和 INNER JOIN 的处理逻辑一致，差别在于只取不满足关联条件的结果，而 INNER JOIN 对 NULL 值是不敏感的），得到的结果就不对了。

为了解决 NOT IN 和 <>ALL 对 NULL 值敏感的问题，Oracle 推出了改良的 ANTI JOIN（11g 新增了参数 _OPTIMIZER_NULL_AWARE_ANTIJOIN，默认为 true），这种反连接能够处理 NULL 值，Oracle 称其为 Null-Aware Anti Join（在真实的执行计划中显示为 XX ANTI NA）。

6. 小结

到这里我们能解释一个问题：为什么 OB 不能使用 HASH ANTI JOIN ？

原因是关联字段 AGENT_ID 没有 NOT NULL 约束，由于 NOT IN 对 NULL 敏感，不能使用普通的 ANTI JOIN，否则遇到 NULL 结果将不正确。Oracle 11g 推出的 Null-Aware ANTI JOIN 可以处理 NULL 敏感的场景，但是 OB 3.x 还没有这个功能，因此不能使用 HASH ANTI JOIN ，4.x 版本将推出 _OPTIMIZER_NULL_AWARE_ANTIJOIN 参数，和 Oracle 保持一致。

优化建议

既然 NOT IN 对 NULL 敏感，有两个优化方向，先和业务确认 NOT IN 子查询结果集有没有可能出现 NULL，如果不会进一步确认关联字段 AGENT_ID 是否会有 NULL 值，如果不会则下面三种方式任选其一，最佳选择是方法 1，最符合开发规范：

给 AGENT_ID 字段加上 NOT NULL 约束，这样优化器就可以使用 HASH ANTI JOIN 了；
NOT EXISTS 对 NULL 值不敏感，因此可以将 NOT IN 改写（或者也可以改写成 LEFT JOIN WHERE xx IS NULL 这种 ANTI JOIN 语法）：

SELECT AGENT_ID, MAX(REL_AGENT_ID)FROM T_LDIM_AGENT_UPREL t1WHERE NOT EXISTS (select AGENT_IDfrom T_LDIM_AGENT_UPREL t2where t1.agent_id=t2.agent_id and valid_flg = '1')group by AGENT_ID;

改写后的执行计划走了 HASH RIGHT ANTI JOIN，执行耗时只要 50ms：

==========================================================================
|ID|OPERATOR             |NAME                           |EST. ROWS|COST |
--------------------------------------------------------------------------
|0 |HASH GROUP BY        |                               |146      |46828|
|1 | HASH RIGHT ANTI JOIN|                               |149      |46697|
|2 |  SUBPLAN SCAN       |VIEW1                          |13880    |11115|
|3 |   TABLE SCAN        |T2                             |13880    |10906|
|4 |  TABLE SCAN         |T1(I_LDIM_AGENT_UPREL_AGENT_ID)|27760    |10738|
==========================================================================

给父查询、子查询都加上 AND AGENT_ID is NOT NULL 条件，也可以让优化器走 HASH ANTI JOIN：

SELECT AGENT_ID, MAX(REL_AGENT_ID)FROM T_LDIM_AGENT_UPRELWHERE AGENT_ID NOT IN (select AGENT_IDfrom T_LDIM_AGENT_UPRELwhere valid_flg = '1' and AGENT_ID is not null )and AGENT_ID is not null                    group by AGENT_ID;

执行计划：

==========================================================================================
|ID|OPERATOR             |NAME                                           |EST. ROWS|COST |
------------------------------------------------------------------------------------------
|0 |HASH GROUP BY        |                                               |146      |47472|
|1 | HASH RIGHT ANTI JOIN|                                               |149      |47341|
|2 |  SUBPLAN SCAN       |VIEW1                                          |13880    |11173|
|3 |   TABLE SCAN        |T_LDIM_AGENT_UPREL                             |13880    |10965|
|4 |  TABLE SCAN         |T_LDIM_AGENT_UPREL(I_LDIM_AGENT_UPREL_AGENT_ID)|27760    |11324|
==========================================================================================

答疑

问题 1. HASH JOIN 只能用于关联条件的等值查询，不支持连接条件是大于、小于、不等于和 LIKE 的场景。为什么 NOT IN、NOT EXISTS 可以使用 HASH ANTI JOIN？

NOT IN、NOT EXISTS 子查询和 WHERE t1.a!=t2.a 看起来相似，但其实语义是不一样的，下面例子可以说明。NOT IN 的语义其实是说如果有相等的值，则外表结果丢弃，因此本质上 NOT IN 的实现方式还是做等值查找，所以 HASH ANTI JOIN 的实现本质和 HASH JOIN 一样，只是在返回结果时做了相反的判断。

obclient [TESTUSER]> select * from t1 t join t1 tt on t.a!=tt.a;
+------+------+-----+------+------+-----+
| A    | B    | C   | A    | B    | C   |
+------+------+-----+------+------+-----+
|    1 | aaa  | aaa |    2 | bbb  | bbb |
|    1 | aaa  | aaa |    3 | ccc  | ccc |
|    1 | aaa  | aaa |    4 | NULL | ddd |
|    2 | bbb  | bbb |    1 | aaa  | aaa |
|    2 | bbb  | bbb |    3 | ccc  | ccc |
|    2 | bbb  | bbb |    4 | NULL | ddd |
|    3 | ccc  | ccc |    1 | aaa  | aaa |
|    3 | ccc  | ccc |    2 | bbb  | bbb |
|    3 | ccc  | ccc |    4 | NULL | ddd |
|    4 | NULL | ddd |    1 | aaa  | aaa |
|    4 | NULL | ddd |    2 | bbb  | bbb |
|    4 | NULL | ddd |    3 | ccc  | ccc |
+------+------+-----+------+------+-----+
12 rows in set (0.005 sec)obclient [TESTUSER]> select t.* from t1 t where a not in(select tt.a from t1 tt);
Empty set (0.005 sec)

这个还可以用 Oracle 的执行计划和优化报告来验证：

##执行计划的2号算子 HASH JOIN RIGHT ANTI NA 有如下条件，这里能说明是做的等值查找
2 - access("AGENT_ID"="AGENT_ID")##另外可以通过下面方法查看优化器改写后的SQL：
alter session set tracefile_identifier='10053c';
alter session set events '10053 trace name context forever,level 1';
执行 SQL;                             
alter session set events '10053 trace name context off';
cd /u01/oracle/diag/rdbms/repo/repo/trace
cat repo_ora_6702_10053c.trc 在 "Final query after transformations" 部分即为优化器改写后的SQL，关联条件也是等值查询：
Final query after transformations:******* UNPARSED QUERY IS *******
SELECT "T_LDIM_AGENT_UPREL"."AGENT_ID" "AGENT_ID",MAX("T_LDIM_AGENT_UPREL"."REL_AGENT_ID") "MAX(REL_AGENT_ID)" FROM "REPORT"."T_LDIM_AGENT_UPREL" "T_LDIM_AGENT_UPREL","REPORT"."T_LDIM_AGENT_UPREL" "T_LDIM_AGENT_UPREL" WHERE "T_LDIM_AGENT_UPREL"."AGENT_ID"="T_LDIM_AGENT_UPREL"."AGENT_ID" AND "T_LDIM_AGENT_UPREL"."VALID_FLG"='1' GROUP BY "T_LDIM_AGENT_UPREL"."AGENT_ID"
kkoqbc: optimizing query block SEL$5DA710D3 (#1)

问题 2. 为什么 OB 可以使用 NESTED-LOOP ANTI JOIN？它能处理 NULL 敏感？怎么实现的？因为它的实现方式导致了对被驱动表只能全表扫描不能走索引？

从结果来看，OB 的 NESTED-LOOP ANTI JOIN 查询结果正确，能处理 NULL 敏感。

实现方式可以从执行计划看出一些端倪：

==============================================================================================
|ID|OPERATOR              |NAME                                           |EST. ROWS|COST    |
----------------------------------------------------------------------------------------------
|0 |MERGE GROUP BY        |                                               |146      |62970523|
|1 | NESTED-LOOP ANTI JOIN|                                               |149      |62970511|
|2 |  TABLE SCAN          |T_LDIM_AGENT_UPREL(I_LDIM_AGENT_UPREL_AGENT_ID)|27760    |10738   |
|3 |  MATERIAL            |                                               |13880    |11313   |
|4 |   SUBPLAN SCAN       |VIEW1                                          |13880    |11115   |
|5 |    TABLE SCAN        |T_LDIM_AGENT_UPREL                             |13880    |10906   |
==============================================================================================Outputs & filters: 
-------------------------------------0 - output([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0)], [T_FUN_MAX(T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef19c50f0))(0x7eeef19c49e0)]), filter(nil), group([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0)]), agg_func([T_FUN_MAX(T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef19c50f0))(0x7eeef19c49e0)])1 - output([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0)], [T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef19c50f0)]), filter(nil), conds([(T_OP_OR, T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0) = VIEW1.AGENT_ID(0x7eeef19ce070)(0x7eeef19ce360), (T_OP_IS, T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0), NULL, 0)(0x7eeef19cf2e0), (T_OP_IS, VIEW1.AGENT_ID(0x7eeef19ce070), NULL, 0)(0x7eeef19cfee0))(0x7eeef19cec00)]), nl_params_(nil), batch_join=false2 - output([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0)], [T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef19c50f0)]), filter(nil), access([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0)], [T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef19c50f0)]), partitions(p0), is_index_back=false, range_key([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0)], [T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef19c50f0)]), range(MIN,MIN ; MAX,MAX)always true3 - output([VIEW1.AGENT_ID(0x7eeef19ce070)]), filter(nil)4 - output([VIEW1.AGENT_ID(0x7eeef19ce070)]), filter(nil), access([VIEW1.AGENT_ID(0x7eeef19ce070)])5 - output([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef1a609a0)]), filter([T_LDIM_AGENT_UPREL.VALID_FLG(0x7eeef1a606b0) = ?(0x7eeef1a60c90)]), access([T_LDIM_AGENT_UPREL.VALID_FLG(0x7eeef1a606b0)], [T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef1a609a0)]), partitions(p0), is_index_back=false, filter_before_indexback[false], range_key([T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef1a821a0)]), range(MIN ; MAX)always true

把 1 号 NESTED-LOOP ANTI JOIN 算子的 Outputs & filters 单独拿出来看：

 1 - output([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0)], [T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eeef19c50f0)]), filter(nil), conds([(T_OP_OR, T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0) = VIEW1.AGENT_ID(0x7eeef19ce070)(0x7eeef19ce360), (T_OP_IS, T_LDIM_AGENT_UPREL.AGENT_ID(0x7eeef19c3fe0), NULL, 0)(0x7eeef19cf2e0), (T_OP_IS, VIEW1.AGENT_ID(0x7eeef19ce070), NULL, 0)(0x7eeef19cfee0))(0x7eeef19cec00)]), nl_params_(nil), batch_join=false

匹配条件是：

where T_LDIM_AGENT_UPREL.AGENT_ID=VIEW1.AGENT_ID 
Or T_LDIM_AGENT_UPREL.AGENT_ID is NULL -- 判断父查询AGENT_ID是否为空，如果遇到 NULL值，则剔除这行结果
Or VIEW1.AGENT_ID is NULL -- 判断子查询结果集 AGENT_ID是否为 NULL，如果遇到NULL值，直接进入JOIN_END阶段，不返回任何数据

以上逻辑是可以实现 NULL 值敏感的。

按照这个逻辑，即使加上 Or VIEW1.AGENT_ID IS NULL 条件，被驱动表依然是可以使用索引的，只有 IS NOT NULL 无法使用索引：

##SQL
select AGENT_ID from T_LDIM_AGENT_UPREL 
where AGENT_ID='124253' or AGENT_ID is null;##执行计划
==============================================================================
|ID|OPERATOR  |NAME                                           |EST. ROWS|COST|
------------------------------------------------------------------------------
|0 |TABLE SCAN|T_LDIM_AGENT_UPREL(I_LDIM_AGENT_UPREL_AGENT_ID)|1        |46  |
==============================================================================Outputs & filters: 
-------------------------------------0 - output([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eef739f9120)]), filter(nil), access([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eef739f9120)]), partitions(p0), is_index_back=false, range_key([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eef739f9120)], [T_LDIM_AGENT_UPREL.REL_AGENT_ID(0x7eef73a40830)]), range(124253,MIN ; 124253,MAX), (NULL,MIN ; NULL,MAX), range_cond([T_LDIM_AGENT_UPREL.AGENT_ID(0x7eef739f9120) = ?(0x7eef739f7a50) OR (T_OP_IS, T_LDIM_AGENT_UPREL.AGENT_ID(0x7eef739f9120), NULL, 0)(0x7eef739f86d0)(0x7eef739f6dd0)])

按照经验，此时我们应该到 Oracle 上看看 NESTED-LOOP ANTI JOIN NA 的处理逻辑，不过在 Oracle 上调不出这个执行计划，因此线索中断。

推断：目前 3.x 版本没有实现真正意义上的 NESTED-LOOP ANTI JOIN NA，但是 NESTED-LOOP ANTI JOIN 可以正确处理 NULL 敏感。4.x 会实现 NESTED-LOOP ANTI JOIN NA，实现方式就是我们前面推理出的逻辑，也就是说 3.x 用的不是这一套逻辑，执行计划虽然这么显示，但实际不一样，对被驱动表匹配查询时就是要遍历全表，不能直接走索引匹配。

问题 3. 加/*+ no_rewrite */后，走 SUBPLAN FILTER 算子，父查询显示可以走索引，为什么执行效率还是慢？

加 /*+ no_rewrite */ 的执行计划，执行耗时 7 秒，比原始 SQL 耗时 16 秒快，从执行逻辑来看：

这里是非相关子查询，每次重复执行的结果都是一样的，所以执行一次后保存在参数集合中（init_plan_idxs_([1]) 表示子查询只需要执行一次）。
从参数中拿到右边非相关子查询的结果，下推 FILTER 到左边计划，执行父查询，注意看条件是 A.AGENT_ID!= ALL(subquery(1))，这里是 !=，因此无法使用索引快速过滤数据，需要扫描整个索引，所以执行效率并不高。如果这里不是 NOT IN 而是 IN，则可以走索引快速查找。

======================================================================
|ID|OPERATOR       |NAME                          |EST. ROWS|COST    |
----------------------------------------------------------------------
|0 |MERGE GROUP BY |                              |3659     |58062035|
|1 | SUBPLAN FILTER|                              |13880    |58061224|
|2 |  TABLE SCAN   |A(I_LDIM_AGENT_UPREL_AGENT_ID)|27760    |10738   |
|3 |  TABLE SCAN   |B                             |13880    |10906   |
======================================================================Outputs & filters: 
-------------------------------------0 - output([A.AGENT_ID(0x7ee843c44330)], [T_FUN_MAX(A.REL_AGENT_ID(0x7ee843c45440))(0x7ee843c44d30)]), filter(nil), group([A.AGENT_ID(0x7ee843c44330)]), agg_func([T_FUN_MAX(A.REL_AGENT_ID(0x7ee843c45440))(0x7ee843c44d30)])1 - output([A.AGENT_ID(0x7ee843c44330)], [A.REL_AGENT_ID(0x7ee843c45440)]), filter([A.AGENT_ID(0x7ee843c44330) != ALL(subquery(1)(0x7ee843bf8e60))(0x7ee843bf8470)]), exec_params_(nil), onetime_exprs_(nil), init_plan_idxs_([1])2 - output([A.AGENT_ID(0x7ee843c44330)], [A.REL_AGENT_ID(0x7ee843c45440)]), filter(nil), access([A.AGENT_ID(0x7ee843c44330)], [A.REL_AGENT_ID(0x7ee843c45440)]), partitions(p0), is_index_back=false, range_key([A.AGENT_ID(0x7ee843c44330)], [A.REL_AGENT_ID(0x7ee843c45440)]), range(MIN,MIN ; MAX,MAX)always true3 - output([B.AGENT_ID(0x7ee843c41350)]), filter([B.VALID_FLG(0x7ee843c40c40) = ?(0x7ee843c40520)]), access([B.VALID_FLG(0x7ee843c40c40)], [B.AGENT_ID(0x7ee843c41350)]), partitions(p0), is_index_back=false, filter_before_indexback[false], range_key([B.REL_AGENT_ID(0x7ee843cb5bb0)]), range(MIN ; MAX)always true