一:什么是Oracle执行计划?数据库
执行计划是一条查询语句在Oracle中的执行过程或访问路径的描述,注意,是查询语句。数据结构
二:怎样查看Oracle执行计划?函数
以PLSQL为例:工具
执行计划的经常使用列字段解释:优化
基数(Rows):Oracle估计的当前操做的返回结果集行数ui
字节(Bytes):执行该步骤后返回的字节数spa
耗费(COST)、CPU耗费:Oracle估计的该步骤的执行成本,用于说明SQL执行的代价,理论上越小越好(该值可能与实际有出入)3d
时间(Time):Oracle估计的当前操做所需的时间对象
1):打开执行计划:blog
在SQL窗口选中一条 SELECT 语句后,或者选中Tools > Explain Plan,或者按 F5 便可查看刚刚执行的这条查询语句的执行计划
打开执行计划后,能够点击配置按钮进行显示配置。如图
进入以下界面
中文版图解,英语较差的童鞋能够参考。
三:看懂Oracle执行计划
①:执行顺序:
根据上图中description列的缩进来判断,缩进最多的最早执行,缩进相同时,最上面的最早执行,能够经过点击图中箭头,查看执行顺序。
对图中动做的一些说明:
1. 上图中 TABLE ACCESS BY … 即描述的是该动做执行时表访问(或者说Oracle访问数据)的方式;
表访问的几种方式:(非所有)
(1) TABLE ACCESS FULL(全表扫描):
Oracle会读取表中全部的行,并检查每一行是否知足SQL语句中的 Where 限制条件;
全表扫描时可使用多块读(即一次I/O读取多块数据块)操做,提高吞吐量;
使用建议:数据量太大的表不建议使用全表扫描,除非自己须要取出的数据较多,占到表数据总量的 5% ~ 10% 或以上
(2) TABLE ACCESS BY ROWID(经过ROWID的表存取) :
先说一下什么是ROWID?
ROWID是由Oracle自动加在表中每行最后的一列伪列,既然是伪列,就说明表中并不会物理存储ROWID的值;
你能够像使用其它列同样使用它,只是不能对该列的值进行增、删、改操做;
一旦一行数据插入后,则其对应的ROWID在该行的生命周期内是惟一的,即便发生行迁移,该行的ROWID值也不变。
让咱们再回到 TABLE ACCESS BY INDEX ROWID 来,INDEX指索引列,也就是说,这里走的是索引的表的ROWID。
行的ROWID指出了该行所在的数据文件、数据块以及行在该块中的位置,因此经过ROWID能够快速定位到目标数据上,这也是Oracle中存取单行数据最快的方法;
(3) INDEX FULL SCAN(索引扫描):
在索引块中,既存储每一个索引的键值,也存储具备该键值的行的ROWID。
一个数字列上建索引后该索引可能的概念结构以下图:
因此索引扫描其实分为两步:
Ⅰ:扫描索引获得对应的ROWID
Ⅱ:经过ROWID定位到具体的行读取数据
---------------------------------------------------------------------------索引扫描延伸---------------------华丽丽的分割线--------------------------------------------------------------------------------------------
索引扫描分五种:
a) INDEX UNIQUE SCAN(索引惟一扫描):
针对惟一性索引(UNIQUE INDEX)的扫描,每次至多只返回一条记录;
表中某字段存在 UNIQUE、PRIMARY KEY 约束时,Oracle常实现惟一性扫描;
b) INDEX RANGE SCAN(索引范围扫描):
使用一个索引存取多行数据;
发生索引范围扫描的三种状况:
c) INDEX FULL SCAN(索引全扫描):
进行全索引扫描时,查询出的数据都必须从索引中能够直接获得(注意全索引扫描只有在CBO模式下才有效)
-----------------Oracle优化器简述----------------华丽转身到ORACLE 11G ,丢掉8i 之前的旧观念-------------------------------------------------------------------------------------
Oracle中的优化器是SQL分析和执行的优化工具,它负责生成、制定SQL的执行计划。
Oracle的优化器有两种:
RBO:
RBO有严格的使用规则,只要按照这套规则去写SQL语句,不管数据表中的内容怎样,也不会影响到你的执行计划;
换句话说,RBO对数据“不敏感”,它要求SQL编写人员必需要了解各项细则;
RBO一直沿用至ORACLE 9i,从ORACLE 10g开始,RBO已经完全被抛弃。
CBO:
CBO是一种比RBO更加合理、可靠的优化器,在ORACLE 10g中彻底取代RBO;
CBO经过计算各类可能的执行计划的“代价”,即COST,从中选用COST最低的执行方案做为实际运行方案;
它依赖数据库对象的统计信息,统计信息的准确与否会影响CBO作出最优的选择,也就是对数据“敏感”。
-------------------------------------------------------------------------------回到正题---------------------------------------------------------------
d) INDEX FAST FULL SCAN(索引快速扫描):
扫描索引中的全部的数据块,与 INDEX FULL SCAN 相似,可是一个显著的区别是它不对查询出的数据进行排序(即数据不是以排序顺序被返回)
e) INDEX SKIP SCAN(索引跳跃扫描):
Oracle 9i后提供,有时候复合索引的前导列(索引包含的第一列)没有在查询语句中出现,oralce也会使用该复合索引,这时候就使用的INDEX SKIP SCAN;
何时会触发 INDEX SKIP SCAN 呢?
前提条件:表有一个复合索引,且在查询时有除了前导列(索引中第一列)外的其余列做为条件,而且优化器模式为CBO时
当Oracle发现前导列的惟一值个数不多时,会将每一个惟一值都做为常规扫描的入口,在此基础上作一次查找,最后合并这些查询;
例如:
假设表emp有ename(雇员名称)、job(职位名)、sex(性别)三个字段,而且创建了如 create index idx_emp on emp (sex, ename, job) 的复合索引;
由于性别只有 '男' 和 '女' 两个值,因此为了提升索引的利用率,Oracle可将这个复合索引拆成 ('男', ename, job),('女', ename, job) 这两个复合索引;
当查询 select * from emp where job = 'Programmer' 时,该查询发出后:
Oracle先进入sex为'男'的入口,这时候使用到了 ('男', ename, job) 这条复合索引,查找 job = 'Programmer' 的条目;
再进入sex为'女'的入口,这时候使用到了 ('女', ename, job) 这条复合索引,查找 job = 'Programmer' 的条目;
最后合并查询到的来自两个入口的结果集。
----------------------------------------------
2. 上图中的 NESTED LOOPS … 描述的是表链接方式;
JOIN 关键字用于将两张表做链接,一次只能链接两张表,JOIN 操做的各步骤通常是串行的(在读取作链接的两张表的数据时能够并行读取);
表(row source)之间的链接顺序对于查询效率有很大的影响,对首先存取的表(驱动表)先应用某些限制条件(Where过滤条件)以获得一个较小的row source,可使得链接效率提升。
-------------------------延伸阅读:驱动表(Driving Table)与匹配表(Probed Table)-------------------------
驱动表(Driving Table):
表链接时首先存取的表,又称外层表(Outer Table),这个概念用于 NESTED LOOPS(嵌套循环) 与 HASH JOIN(哈希链接)中;
若是驱动表返回较多的行数据,则对全部的后续操做有负面影响,故通常选择小表(应用Where限制条件后返回较少行数的表)做为驱动表。
匹配表(Probed Table):
又称为内层表(Inner Table),从驱动表获取一行具体数据后,会到该表中寻找符合链接条件的行。故该表通常为大表(应用Where限制条件后返回较多行数的表)。
---------------------------------------------------------------------------------------------------------
表链接的几种方式:
注:这里将首先存取的表称做 row source 1,将以后参与链接的表称做 row source 2;
(1) SORT MERGE JOIN(排序-合并链接):
假设有查询:select a.name, b.name from table_A a join table_B b on (a.id = b.id)
内部链接过程:
a) 生成 row source 1 须要的数据,按照链接操做关联列(如示例中的a.id)对这些数据进行排序
b) 生成 row source 2 须要的数据,按照与 a) 中对应的链接操做关联列(b.id)对数据进行排序
c) 两边已排序的行放在一块儿执行合并操做(对两边的数据集进行扫描并判断是否链接)
延伸:
若是示例中的链接操做关联列 a.id,b.id 以前就已经被排过序了的话,链接速度即可大大提升,由于排序是很费时间和资源的操做,尤为对于有大量数据的表。
故能够考虑在 a.id,b.id 上创建索引让其能预先排好序。不过遗憾的是,因为返回的结果集中包括全部字段,因此一般的执行计划中,即便链接列存在索引,也不会进入到执行计划中,除非进行一些特定列处理(如仅仅只查询有索引的列等)。
排序-合并链接的表无驱动顺序,谁在前面均可以;
排序-合并链接适用的链接条件有: < <= = > >= ,不适用的链接条件有: <> like
(2) NESTED LOOPS(嵌套循环):
内部链接过程:
a) 取出 row source 1 的 row 1(第一行数据),遍历 row source 2 的全部行并检查是否有匹配的,取出匹配的行放入结果集中
b) 取出 row source 1 的 row 2(第二行数据),遍历 row source 2 的全部行并检查是否有匹配的,取出匹配的行放入结果集中
c) ……
若 row source 1 (即驱动表)中返回了 N 行数据,则 row source 2 也相应的会被全表遍历 N 次。
由于 row source 1 的每一行都会去匹配 row source 2 的全部行,因此当 row source 1 返回的行数尽量少而且能高效访问 row source 2(如创建适当的索引)时,效率较高。
延伸:
嵌套循环的表有驱动顺序,注意选择合适的驱动表。
嵌套循环链接有一个其余链接方式没有的好处是:能够先返回已经链接的行,而没必要等全部的链接操做处理完才返回数据,这样能够实现快速响应。
应尽量使用限制条件(Where过滤条件)使驱动表(row source 1)返回的行数尽量少,同时在匹配表(row source 2)的链接操做关联列上创建惟一索引(UNIQUE INDEX)或是选择性较好的非惟一索引,此时嵌套循环链接的执行效率会变得很高。若驱动表返回的行数较多,即便匹配表链接操做关联列上存在索引,链接效率也不会很高。
(3)HASH JOIN(哈希链接) :
哈希链接只适用于等值链接(即链接条件为 = )
HASH JOIN对两个表作链接时并不必定是都进行全表扫描,其并不限制表访问方式;
内部链接过程简述:
a) 取出 row source 1(驱动表,在HASH JOIN中又称为Build Table) 的数据集,而后将其构建成内存中的一个 Hash Table(Hash函数的Hash KEY就是链接操做关联列),建立Hash位图(bitmap)
b) 取出 row source 2(匹配表)的数据集,对其中的每一条数据的链接操做关联列使用相同的Hash函数并找到对应的 a) 里的数据在 Hash Table 中的位置,在该位置上检查可否找到匹配的数据
----------------延伸阅读:Hash Table相关----------------
来自Wiki的解释:
In computing, a hash table (hash map) is a data structure used to implement an associative array, a structure that can map keys to values. A hash table uses a hash function to compute an index into an array of buckets or slots, from which the desired value can be found.
散列(hash)技术:在记录的存储位置和记录具备的关键字key之间创建一个对应关系 f ,使得输入key后,能够获得对应的存储位置 f(key),这个对应关系 f 就是散列(哈希)函数;
采用散列技术将记录存储在一块连续的存储空间中,这块连续的存储空间就是散列表(哈希表);
不一样的key经同一散列函数散列后获得的散列值理论上应该不一样,可是实际中有可能相同,相同时便是发生了散列(哈希)冲突,解决散列冲突的办法有不少,好比HashMap中就是用链地址法来解决哈希冲突;
哈希表是一种面向查找的数据结构,在输入给定值后查找给定值对应的记录在表中的位置以获取特定记录这个过程的速度很快。
--------------------------------------------------------
HASH JOIN的三种模式:
1) OPTIMAL HASH JOIN:
OPTIMAL 模式是从驱动表(也称Build Table)上获取的结果集比较小,能够把根据结果集构建的整个Hash Table都创建在用户可使用的内存区域里。
链接过程简述:
Ⅰ:首先对Build Table内各行数据的链接操做关联列使用Hash函数,把Build Table的结果集构建成内存中的Hash Table。如图所示,能够把Hash Table看做内存中的一块大的方形区域,里面有不少的小格子,Build Table里的数据就分散分布在这些小格子中,而这些小格子就是Hash Bucket(见上面Wiki的定义)。
Ⅱ:开始读取匹配表(Probed Table)的数据,对其中每行数据的链接操做关联列都使用同上的Hash函数,定位Build Table里使用Hash函数后具备相同值数据所在的Hash Bucket。
Ⅲ:定位到具体的Hash Bucket后,先检查Bucket里是否有数据,没有的话就立刻丢掉匹配表(Probed Table)的这一行。若是里面有数据,则继续检查里面的数据(驱动表的数据)是否和匹配表的数据相匹配。
2): ONEPASS HASH JOIN :
从驱动表(也称Build Table)上获取的结果集较大,没法将根据结果集构建的Hash Table所有放入内存中时,会使用 ONEPASS 模式。
链接过程简述:
Ⅰ:对Build Table内各行数据的链接操做关联列使用Hash函数,根据Build Table的结果集构建Hash Table后,因为内存没法放下全部的Hash Table内容,将致使有的Hash Bucket放在内存里,有的Hash Bucket放在磁盘上,不管放在内存里仍是磁盘里,Oracle都使用一个Bitmap结构来反映这些Hash Bucket的状态(包括其位置和是否有数据)。
Ⅱ:读取匹配表数据并对每行的链接操做关联列使用同上的Hash函数,定位Bitmap上Build Table里使用Hash函数后具备相同值数据所在的Bucket。若是该Bucket为空,则丢弃匹配表的这条数据。若是不为空,则须要看该Bucket是在内存里仍是在磁盘上。
若是在内存中,就直接访问这个Bucket并检查其中的数据是否匹配,有匹配的话就返回这条查询结果。
若是在磁盘上,就先把这条待匹配数据放到一边,将其先暂存在内存里,等之后积累了必定量的这样的待匹配数据后,再批量的把这些数据写入到磁盘上(上图中的 Dump probe partitions to disk)。
Ⅲ:当把匹配表完整的扫描了一遍后,可能已经返回了一部分匹配的数据了。接下来还有Hash Table中一部分在磁盘上的Hash Bucket数据以及匹配表中部分被写入到磁盘上的待匹配数据未处理,如今Oracle会把磁盘上的这两部分数据从新匹配一次,而后返回最终的查询结果。
3): MULTIPASS HASH JOIN:
当内存特别小或者相对而言Hash Table的数据特别大时,会使用 MULTIPASS 模式。MULTIPASS会屡次读取磁盘数据,应尽可能避免使用该模式。