我不是在寻找以下优化，只是一个解释.我有这个查询：

SELECT COUNT(LARGE_A.id_a), SUM(LARGE_A.b_integer)
FROM LARGE_A
INNER JOIN MEDIUM_A ON LARGE_A.id_a = MEDIUM_A.id
INNER JOIN MEDIUM_B ON LARGE_A.id_b = MEDIUM_B.id
WHERE
    MEDIUM_A.a_varchar2 LIKE 'Example%' AND
    EXTRACT(YEAR FROM MEDIUM_B.a_datetime) = 2000 AND
    LARGE_A.a_integer BETWEEN 0 AND 1000;

属性的类型写在它们的名称中。ID是整数。表LARGE_A有1 000 000行，中等的有100 000行。ID是主键，但是表LARGE_A有一个复合键(id_a, id_b)。
然后我从V$SQL视图中得到了以下执行计划，因为Autotrace在这一点上撒谎了。

SELECT STATEMENT                        
|SORT AGGREGATE                         
||HASH JOIN                             
|||NESTED LOOPS                         
||||NESTED LOOPS                        
|||||STATISTICS COLLECTOR               
||||||NESTED LOOPS                      
|||||||TABLE ACCESS FULL                LARGE_A
|||||||TABLE ACCESS BY INDEX ROWID      MEDIUM_A
||||||||INDEX UNIQUE SCAN               PK(MEDIUM_A)
|||||INDEX UNIQUE SCAN                  PK(MEDIUM_B)
||||TABLE ACCESS BY INDEX ROWID         MEDIUM_B
|||TABLE ACCESS FULL                    MEDIUM_B

PK表示括号中给出的表的主键（整数）上的非聚集索引。这里我不使用IOT。
为什么优化器首先从索引PK(MEDIUM_B)中逐个查询记录，然后使用ROWID获取其余的行，然后再次运行FULL表扫描？