Oracle：嵌套循环的内部行源 - 估计行数不正确？
Oracle: Inner Row Source of Nested Loop - Incorrect Estimated Rows?
我的理解是，嵌套循环连接的内部行源的解释计划中的估计行数反映了该嵌套循环的一次迭代的行数。
在下面的示例中，解释计划的第 6 步是嵌套循环连接的内部行源，它一次通过一个 ROWID 获取一行。因此，它的估计行数应该为 1（每个 ROWID 只有 1 行）。
为什么第 6 步的 table access by index ROWID 显示 100（我预计它会显示 1）？
使用 Oracle 19c 企业版。
drop table "C";
drop table "P";
create table "P"
( p_id NUMBER
, p_num NUMBER
, p_pad CHAR(200 byte)
)
;
insert
into "P" (p_id, p_num, p_pad)
select level
, mod(level-1,200/2)
, ' '
from dual
connect by level <= 200
;
create table "C"
( c_id NUMBER
, p_id NUMBER
, c_pad CHAR(200 byte)
)
;
insert /*+ append enable_parallel_dml parallel (auto) */
into "C" (c_id, p_id, c_pad)
with
"D" as
( select /*+ materialize */ null from dual connect by level <= 100
)
select rownum c_id
, p_id p_id
, ' ' c_pad
from "P", "D"
;
commit;
create index IX_P on p (p_num);
create unique index IU_P on p (p_id);
alter table p add constraint UK_P unique (p_id) rely using index IU_P enable validate;
alter table C add constraint R_C foreign key (p_id) references p (p_id) rely enable validate;
create index IR_C on _C (p_id);
exec dbms_stats.gather_table_stats(OwnName => null, TabName => 'P', cascade => true);
exec dbms_stats.gather_table_stats(OwnName => null, TabName => 'C', cascade => true);
select /*+ optimizer_features_enable('19.1.0')
use_nl (P C) */
*
from "P"
join "C"
on P.p_id = C.p_id
and P.p_num = 1
;
plan hash value: 3840235794
----------------------------------------------------------------------------------------------
| id | Operation | name | rows | Bytes | cost (%CPU)| time |
----------------------------------------------------------------------------------------------
| 0 | select statement | | 200 | 83000 | 205 (0)| 00:00:01 |
| 1 | nested LOOPS | | 200 | 83000 | 205 (0)| 00:00:01 |
| 2 | nested LOOPS | | 200 | 83000 | 205 (0)| 00:00:01 |
| 3 | table access by index ROWID BATCHED| P | 2 | 414 | 3 (0)| 00:00:01 |
|* 4 | index range scan | IX_P | 2 | | 1 (0)| 00:00:01 |
|* 5 | index range scan | IR_C | 100 | | 1 (0)| 00:00:01 |
| 6 | table access by index ROWID | C | 100 | 20800 | 101 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("P"."P_NUM"=1)
5 - access("P"."P_ID"="C"."P_ID")
外部行源步骤 3 乘以内部行源步骤 5 = 嵌套循环步骤 2。
但是，外部行源步骤 2 乘以内部行源步骤 6 <> 嵌套循环步骤 1。
我同意第 1 步的总数应该是 200，但不明白为什么第 6 步的估计行数为 100。
为什么第 6 步的估计行数是 100 而不是 1？
提前致谢。
我认为 this Oracle documentation paragraph 很好地解释了这种情况：
Multiple nested loops operations can occasionally show up in the execution plan for just one join, which indicates that Oracle used the nested-loop batching optimization technique. What this method does is transform a single join of two row sources into a join of the driving row source to one copy of the probe row source that is joined to a replica of itself on ROWID; since we now have three row sources, we need at least two nested loops. The probe row source copy that is used to perform a self join on ROWID is used to filter rows, so it will have a corresponding TABLE ACCESS BY ... ROWID entry in the execution plan. This cost-based optimization can often reduce I/O although the execution plan may not transparently display the benefits.
您示例中的第 6 步是“探测行源副本”；它基本上是 table C 的缓存版本，所以它有 100 行。但它的成本由所有外部嵌套循环共享 - table 只被访问过一次 - 所以它已经包含在第 2 步的总数中。（我认为？）
在这里您可以看到外部 NESTED LOOP
中预期的行数
select p_id, count(*) from C where p_id in (
select p_id from P where p_num = 1)
group by p_id;
P_ID COUNT(*)
---------- ----------
2 100
102 100
所以实际上每次迭代都希望获得 100 行。
如果您 运行 使用提示 gather_plan_statistics 的查询，您可以看到 Starts 的数量和实际总行数 A-Rows。
select /*+ gather_plan_statistics use_nl (P C) */
*
from "P"
join "C"
on P.p_id = C.p_id
and P.p_num = 1
SQL_ID 927pggk6scpwt, child number 0
-------------------------------------
select /*+ gather_plan_statistics use_nl (P C) */ * from "P"
join "C" on P.p_id = C.p_id and P.p_num = 1
Plan hash value: 2326820011
--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 200 |00:00:00.01 | 213 |
| 1 | NESTED LOOPS | | 1 | 200 | 200 |00:00:00.01 | 213 |
| 2 | NESTED LOOPS | | 1 | 200 | 200 |00:00:00.01 | 13 |
| 3 | TABLE ACCESS BY INDEX ROWID BATCHED| P | 1 | 2 | 2 |00:00:00.01 | 5 |
|* 4 | INDEX RANGE SCAN | IX_P | 1 | 2 | 2 |00:00:00.01 | 3 |
|* 5 | INDEX RANGE SCAN | IR_C | 2 | 100 | 200 |00:00:00.01 | 8 |
| 6 | TABLE ACCESS BY INDEX ROWID | C | 200 | 100 | 200 |00:00:00.01 | 200 |
--------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("P"."P_NUM"=1)
5 - access("P"."P_ID"="C"."P_ID")
即操作 5 开始 两次（第 Starts 列），总 200 行（第 A-Rows 列）
操作 6 每次启动 200 次以获得 一个 行。
我的理解是，嵌套循环连接的内部行源的解释计划中的估计行数反映了该嵌套循环的一次迭代的行数。
在下面的示例中，解释计划的第 6 步是嵌套循环连接的内部行源，它一次通过一个 ROWID 获取一行。因此，它的估计行数应该为 1（每个 ROWID 只有 1 行）。
为什么第 6 步的 table access by index ROWID 显示 100（我预计它会显示 1）？
使用 Oracle 19c 企业版。
drop table "C";
drop table "P";
create table "P"
( p_id NUMBER
, p_num NUMBER
, p_pad CHAR(200 byte)
)
;
insert
into "P" (p_id, p_num, p_pad)
select level
, mod(level-1,200/2)
, ' '
from dual
connect by level <= 200
;
create table "C"
( c_id NUMBER
, p_id NUMBER
, c_pad CHAR(200 byte)
)
;
insert /*+ append enable_parallel_dml parallel (auto) */
into "C" (c_id, p_id, c_pad)
with
"D" as
( select /*+ materialize */ null from dual connect by level <= 100
)
select rownum c_id
, p_id p_id
, ' ' c_pad
from "P", "D"
;
commit;
create index IX_P on p (p_num);
create unique index IU_P on p (p_id);
alter table p add constraint UK_P unique (p_id) rely using index IU_P enable validate;
alter table C add constraint R_C foreign key (p_id) references p (p_id) rely enable validate;
create index IR_C on _C (p_id);
exec dbms_stats.gather_table_stats(OwnName => null, TabName => 'P', cascade => true);
exec dbms_stats.gather_table_stats(OwnName => null, TabName => 'C', cascade => true);
select /*+ optimizer_features_enable('19.1.0')
use_nl (P C) */
*
from "P"
join "C"
on P.p_id = C.p_id
and P.p_num = 1
;
plan hash value: 3840235794
----------------------------------------------------------------------------------------------
| id | Operation | name | rows | Bytes | cost (%CPU)| time |
----------------------------------------------------------------------------------------------
| 0 | select statement | | 200 | 83000 | 205 (0)| 00:00:01 |
| 1 | nested LOOPS | | 200 | 83000 | 205 (0)| 00:00:01 |
| 2 | nested LOOPS | | 200 | 83000 | 205 (0)| 00:00:01 |
| 3 | table access by index ROWID BATCHED| P | 2 | 414 | 3 (0)| 00:00:01 |
|* 4 | index range scan | IX_P | 2 | | 1 (0)| 00:00:01 |
|* 5 | index range scan | IR_C | 100 | | 1 (0)| 00:00:01 |
| 6 | table access by index ROWID | C | 100 | 20800 | 101 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("P"."P_NUM"=1)
5 - access("P"."P_ID"="C"."P_ID")
外部行源步骤 3 乘以内部行源步骤 5 = 嵌套循环步骤 2。
但是，外部行源步骤 2 乘以内部行源步骤 6 <> 嵌套循环步骤 1。
我同意第 1 步的总数应该是 200，但不明白为什么第 6 步的估计行数为 100。
为什么第 6 步的估计行数是 100 而不是 1？
提前致谢。
我认为 this Oracle documentation paragraph 很好地解释了这种情况：
Multiple nested loops operations can occasionally show up in the execution plan for just one join, which indicates that Oracle used the nested-loop batching optimization technique. What this method does is transform a single join of two row sources into a join of the driving row source to one copy of the probe row source that is joined to a replica of itself on ROWID; since we now have three row sources, we need at least two nested loops. The probe row source copy that is used to perform a self join on ROWID is used to filter rows, so it will have a corresponding
TABLE ACCESS BY ... ROWIDentry in the execution plan. This cost-based optimization can often reduce I/O although the execution plan may not transparently display the benefits.
您示例中的第 6 步是“探测行源副本”；它基本上是 table C 的缓存版本，所以它有 100 行。但它的成本由所有外部嵌套循环共享 - table 只被访问过一次 - 所以它已经包含在第 2 步的总数中。（我认为？）
在这里您可以看到外部 NESTED LOOP
select p_id, count(*) from C where p_id in (
select p_id from P where p_num = 1)
group by p_id;
P_ID COUNT(*)
---------- ----------
2 100
102 100
所以实际上每次迭代都希望获得 100 行。
如果您 运行 使用提示 gather_plan_statistics 的查询，您可以看到 Starts 的数量和实际总行数 A-Rows。
select /*+ gather_plan_statistics use_nl (P C) */
*
from "P"
join "C"
on P.p_id = C.p_id
and P.p_num = 1
SQL_ID 927pggk6scpwt, child number 0
-------------------------------------
select /*+ gather_plan_statistics use_nl (P C) */ * from "P"
join "C" on P.p_id = C.p_id and P.p_num = 1
Plan hash value: 2326820011
--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 200 |00:00:00.01 | 213 |
| 1 | NESTED LOOPS | | 1 | 200 | 200 |00:00:00.01 | 213 |
| 2 | NESTED LOOPS | | 1 | 200 | 200 |00:00:00.01 | 13 |
| 3 | TABLE ACCESS BY INDEX ROWID BATCHED| P | 1 | 2 | 2 |00:00:00.01 | 5 |
|* 4 | INDEX RANGE SCAN | IX_P | 1 | 2 | 2 |00:00:00.01 | 3 |
|* 5 | INDEX RANGE SCAN | IR_C | 2 | 100 | 200 |00:00:00.01 | 8 |
| 6 | TABLE ACCESS BY INDEX ROWID | C | 200 | 100 | 200 |00:00:00.01 | 200 |
--------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("P"."P_NUM"=1)
5 - access("P"."P_ID"="C"."P_ID")
即操作 5 开始 两次（第 Starts 列），总 200 行（第 A-Rows 列）
操作 6 每次启动 200 次以获得 一个 行。