oracle执行计划，试图理解

EXPLAIN PLAN FOR
  SELECT sightings.sighting_id, spotters.spotter_name,
         sightings.sighting_date
    FROM sightings
         INNER JOIN spotters
                 ON sightings.spotter_id = spotters.spotter_id
   WHERE sightings.spotter_id = 1255;

SELECT plan_table_output
  FROM table(dbms_xplan.display('plan_table',null,'basic'));




id   Operation                         Name
0    select statement        
1      nested loops
2        table access by index rowid   spotters
3          index unique scan           pk_spotter_ID
4        table access full             sightings

我试图了解到底发生了什么，这听起来是对的：

首先评估select语句，并且不在选择列表中的属性将被忽略用于输出

然后嵌套循环计算spotters.spotters_id = sightings.spotter_id上的内部连接

通过索引rowid进行表访问检索包含步骤3从spotters表返回的rowid的行

索引唯一扫描，扫描PK_SPOTTER_ID索引中的spotter_id，并查找spotters表中的rowid关联行

表访问已满，然后完全扫描直到发现sighting_id = 1255

---

这是非正式的，正确的顺序：

-- The index pk_spotter_id is scanned for at most one row that satisfies spotter_id = 1255
3          index unique scan           pk_spotter_ID

-- The spotter_name column is fetched from the table spotters for the previously found row
2        table access by index rowid   spotters

-- A nested loop is run for each (i.e. at most one) of the previously found rows
1      nested loops

-- That nested loop will scan the entire sightings table for rows that match the join
-- predicate sightings.spotter_id = spotters.spotter_id
4        table access full             sightings

-- That'll be it for your select statement
0    select statement        

一般来说（有很多例外），可以读取Oracle执行计划

自下而上

首先是兄弟姐妹

这意味着你沿着树走下去，直到找到第一个叶子操作（例如＃3），它将被“首先”执行，其结果被馈送给父级（例如＃2），然后所有的兄弟都被执行所有的兄弟姐妹的结果也会被馈送给父母，然后父母的结果会被馈送给父母（例如＃1），直到您达到顶级操作。

这是对发生的事情的非正式解释。 请注意，一旦陈述变得更加复杂，这些规则将会有许多例外。

---

步骤似乎基本正确，但应该是按钮式。 投影（选择相关列）在扫描阶段尽可能早地完成。 索引操作是SEEK（你没有扫描整个索引）

---

注意：这个答案反映了问题的原始版本。

Oracle正在整体阅读这两个表格。

它基于join键对每个表格进行散列 - 对表格进行“重新排序”，以使相似的键出现在彼此附近。

它正在加入。

然后进行最终select的计算并将结果返回给用户。

链接地址: http://www.djcxy.com/p/60721.html

上一篇: oracle execution plan, trying to understand

下一篇: Oracle query using 'like' on indexed number column, poor performance