ORACLE中的常见执行计划
原文发表在http://l4j.cc/2019/04/21/oralce-access-path-introduce/数据库
本文梳理、概括了在以前工做中常见的一些执行计划。了解ORACLE中有哪些可能的执行计划，以及什么状况下适合哪一种执行计划是进行SQL优化的基础。bash
表访问相关
Full Table Scans
全表扫描首先会读取表中的全部行，而后过滤掉不知足条件的数据。全表扫描时，数据库会以此读取HWM下的全部格式化了的数据块，此时数据库一般会作multiblock read来提升性能，单次读取的数据块由DB_FILE_MULTIBLOCK_READ_COUNT参数指定。 如下状况会作全表扫描：oracle
- 查询列上不存在索引
- 在索引列上使用了函数
- 执行SELECT COUNT(*)语句，存在索引，可是索引包含空值
- 未使用B-TREE索引的前导列。如存在employees(first_name,last_name)的索引，可是查询条件为WHERE last_name='KING'。可是优化器有可能选择index skip scan
- 查询选择性很低的时候
- 统计信息陈旧
- 当表很小的时候，包含的数据块数n小于DB_FILE_MULTIBLOCK_READ_COUNT参数指定的值
- 当表具备很高的并行度的时候
- 使用了FULL的hints
下面是一个作全表扫描的列子，其执行计划的关键字为'TABLE ACCESS FULL'：ide
SQL> select owner,table_name from test_env.tb_table_list where owner='AUDSYS'; OWNER TABLE_NAME -------------------- ------------------------------ AUDSYS AUD$UNIFIED SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select owner,table_name from test_env.tb_table_list where owner='AUDSYS' Plan hash value: 1475094007 ------------------------------------------- | Id | Operation | Name | ------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL| TB_TABLE_LIST | PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------------
Table Access By Rowid
ROWID是数据在数据库中存储位置的内部表示，它是用来定位单个行最快的方式。一般数据库经过索引检索数据行或者指定rowid查询的时候会使用这种访问方式。函数
SQL> select owner,table_name from test_env.tb_table_list where TABLE_NAME='ACCESS$'; OWNER TABLE_NAME -------------------- ------------------------------ SYS ACCESS$ SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select owner,table_name from test_env.tb_table_list where TABLE_NAME='ACCESS$' Plan hash value: 3473397811 ------------------------------------------------------------------------ | Id | Operation | Name | ------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------- | 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 2 | INDEX RANGE SCAN | IDX_TB_TABLE_LIST_TBNAME | ------------------------------------------------------------------------
TABLE ACCESS BY INDEX ROWID BATCHED表示数据库经过索引中获得的rowid来检索数据，BATCHED的访问方式，表示数据库会从索引中检索一批ROWID，而后按块顺序访问行，减小访问数据块的次数来提高性能。这是ORACLE 12C的一个新特性。在11g中上面的执行计划表示为TABLE ACCESS BY INDEX ROWID。oop
Sample Table Scans
这是抽样检索数据的数据访问方式。使用SAMPLE关键字对表中数据进行抽样的时候会使用该执行计划，在执行计划中表现为TABLE ACCESS SAMPLE关键字。它有如下两种形式:性能
- SAMPLE (sample_percent) 数据库读取表中指定百分比的行数据。
- SAMPLE BLOCK (sample_percent) 数据库会读取指定百分比的表数据块。
sample_percent的百分比在[0.000001,100) 范围内。大数据
B-tree索引相关
Index Unique Scans
只有经过CREATE UNIQUE INDEX建立惟一索引，而且在查询的时候谓词条件为等于的时候才会以该方式访问数据。惟一约束(unique和primary key)，可是建立的非惟一索引是不足以让查询走Index Unique Scan的。在执行计划中的关键字是INDEX UNIQUE SCAN。优化
SQL> CREATE UNIQUE INDEX TEST_ENV.IDX_TB_TABLE_LIST_SID ON TEST_ENV.TB_TABLE_LIST(SID); 索引已建立。 SQL> SELECT SID,OWNER,TABLE_NAME FROM TEST_ENV.TB_TABLE_LIST WHERE SID='58223719640640AB8C603BC1B15D5C51'; SID OWNER TABLE_NAME ------------------------------------ -------------------- ------------------------------ 58223719640640AB8C603BC1B15D5C51 SYS ACCESS$ SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ SELECT SID,OWNER,TABLE_NAME FROM TEST_ENV.TB_TABLE_LIST WHERE SID='58223719640640AB8C603BC1B15D5C51' Plan hash value: 3115192837 ------------------------------------------------------------- | Id | Operation | Name | ------------------------------------------------------------- | 0 | SELECT STATEMENT | | PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------------------- | 1 | TABLE ACCESS BY INDEX ROWID| TB_TABLE_LIST | | 2 | INDEX UNIQUE SCAN | IDX_TB_TABLE_LIST_SID | ------------------------------------------------------------- 已选择 15 行。
Index Range Scans
经过该索引字段查询结果可能返回多个值的时候，例如>, <, and以及对非惟一索引的=，就会以该方式访问数据，表如今执行计划上就是INDEX RANGE SCAN关键字。spa
SQL> select owner,table_name from test_env.tb_table_list where TABLE_NAME='ACCESS$'; OWNER TABLE_NAME -------------------- ------------------------------ SYS ACCESS$ SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select owner,table_name from test_env.tb_table_list where TABLE_NAME='ACCESS$' Plan hash value: 3473397811 ------------------------------------------------------------------------ | Id | Operation | Name | ------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------- | 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 2 | INDEX RANGE SCAN | IDX_TB_TABLE_LIST_TBNAME | ------------------------------------------------------------------------
Index Full Scans
索引全扫描会有序的读取整个索引，因为索引是有序的，因此它会消除额外的排序操做。 如下状况会优化器会考虑执行索引全扫描：
- 谓词使用了索引中的列。该列没必要是索引的前导列
- 没有谓词条件，可是查询的列为该索引的列，而且至少有一个列不为空
- 查询包含ORDER BY 语句而且排序字段为非空且有索引
SQL> select table_name from test_env.tb_table_list order by table_name; ...... TABLE_NAME ------------------------------ XSTREAM$_SERVER_CONNECTION XSTREAM$_SUBSET_RULES XSTREAM$_SYSGEN_OBJS _default_auditing_options_ 已选择 2138 行。 SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select table_name from test_env.tb_table_list order by table_name Plan hash value: 2901892796 ----------------------------------------------------- | Id | Operation | Name | ----------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | INDEX FULL SCAN | IDX_TB_TABLE_LIST_TBNAME | PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------
Index Fast Full Scans
当查询的列仅仅包含索引列，且不须要排序的时候，优化器会考虑该访问方式，它会以磁盘存储位置来读取，不会保证数据的有序性。
SQL> select table_name from test_env.tb_table_list; TABLE_NAME ------------------------------ XSTREAM$_SERVER_CONNECTION XSTREAM$_SUBSET_RULES XSTREAM$_SYSGEN_OBJS _default_auditing_options_ 已选择 2138 行。 SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select table_name from test_env.tb_table_list Plan hash value: 3670592075 --------------------------------------------------------- | Id | Operation | Name | --------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | INDEX FAST FULL SCAN| IDX_TB_TABLE_LIST_TBNAME | PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------
Index Skip Scans
在复合索引中未使用前导列的状况，而且前导列只存在不多的distinct value。其在执行计划中表现为INDEX SKIP SCAN。
SQL> create index test_env.idx_tb_table_list_mul on test_env.tb_table_list(owner,table_name); 索引已建立。 SQL> select /*+ index(t idx_tb_table_list_mul) */sid,owner,table_name,status from test_env.tb_table_list t where table_name='ACCESS$'; SID OWNER TABLE_NAME STATUS ------------------------------------ -------------------- ------------------------------ -------- 58223719640640AB8C603BC1B15D5C51 SYS ACCESS$ VALID SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ EXPLAINED SQL STATEMENT: ------------------------ select /*+ index(t idx_tb_table_list_mul) */sid,owner,table_name,status from test_env.tb_table_list t where table_name='ACCESS$' Plan hash value: 124701251 --------------------------------------------------------------------- | Id | Operation | Name | --------------------------------------------------------------------- | 0 | SELECT STATEMENT | | PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ | 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 2 | INDEX SKIP SCAN | IDX_TB_TABLE_LIST_MUL | ---------------------------------------------------------------------
Index Join Scans
对同一个表，多个索引的hash join。当查询结果都是索引中的列，而且存在于不一样索引中时会考虑使用该数据访问方式，可是若是访问表的效率更高则会根据rowid去访问表。 Index join的成本是很是的，绝大多数状况下是不会出现这种状况，经过索引去探测表一般成本更低。
SQL> select owner,table_name from test_env.tb_table_list where ini_trans>=4; OWNER TABLE_NAME --------------- ------------------------------ MDSYS SDO_DIST_METADATA_TABLE SYS AW$AWCREATE SYS AW$AWCREATE10G SYS AW$AWMD SYS AW$AWREPORT SYS AW$AWXML SYS AW$EXPRESS SYS AW_OBJ$ SYS AW_PROP$ SYS OBJECT_USAGE SYS PS$ OWNER TABLE_NAME --------------- ------------------------------ SYS STREAMS$_APPLY_PROGRESS 已选择 12 行。 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'basic')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select owner,table_name from test_env.tb_table_list where ini_trans>=4 Plan hash value: 832528447 --------------------------------------------------------------------- | Id | Operation | Name | --------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | VIEW | index$_join$_001 | PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------- | 2 | HASH JOIN | | | 3 | BITMAP CONVERSION TO ROWIDS| | | 4 | BITMAP INDEX RANGE SCAN | BIDX_TB_TABLE_LIST_INITRANS | | 5 | INDEX FAST FULL SCAN | IDX_TB_TABLE_LIST_MUL | --------------------------------------------------------------------- 已选择 17 行。
Bitmap索引相关
传统的B-tree索引，一条索引对应一条数据。Bitmap的一个索引的键值一般对应一批rowid。 Bitmap索引适用于拥有较低distinct基数而且不常常修改的数据。Bitmap索引不适用于常常进行DML操做的列，由于一个index key指向不少数据行，当对一个索引的列进行修改时，会锁住整个索引条目以及对应的数据行。 还须要注意的一点就是Bitmap索引列是能够包含空值的。
Bitmap Conversion to Rowid
只要从位图索引中检索行，就会用到该访问方式，进行数据行与bitmap之间的转换。
SQL> select owner,table_name,status,ini_trans from test_env.tb_table_list where ini_trans>=4; OWNER TABLE_NAME STATUS INI_TRANS --------------- ------------------------------ ---------- ---------- SYS PS$ VALID 4 SYS AW_OBJ$ VALID 4 SYS AW_PROP$ VALID 4 SYS AW$EXPRESS VALID 4 SYS AW$AWMD VALID 4 SYS AW$AWCREATE VALID 4 SYS AW$AWCREATE10G VALID 4 SYS AW$AWXML VALID 4 SYS AW$AWREPORT VALID 4 SYS OBJECT_USAGE VALID 30 SYS STREAMS$_APPLY_PROGRESS VALID 120 OWNER TABLE_NAME STATUS INI_TRANS --------------- ------------------------------ ---------- ---------- MDSYS SDO_DIST_METADATA_TABLE VALID 255 已选择 12 行。 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'basic')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select owner,table_name,status,ini_trans from test_env.tb_table_list where ini_trans>=4 Plan hash value: 3195249317 --------------------------------------------------------------------------- | Id | Operation | Name | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------- | 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 2 | BITMAP CONVERSION TO ROWIDS | | | 3 | BITMAP INDEX RANGE SCAN | BIDX_TB_TABLE_LIST_INITRANS | --------------------------------------------------------------------------- 已选择 16 行。
Bitmap Index Single Value
使用bitmap索引的单个键值来查询数据的时候会走该访问方式，在执行计划中表现为BITMAP INDEX SINGLE VALUE关键字。
SQL> SELECT OWNER,TABLE_NAME,TABLESPACE_NAME,STATUS FROM TEST_ENV.TB_TABLE_LIST WHERE TABLESPACE_NAME='SYSTEM'; .... OWNER TABLE_NAME TABLESPACE_NAME STATUS --------------- ------------------------------ -------------------- ---------- LBACSYS OLS$USER_LEVELS SYSTEM VALID LBACSYS OLS$USER_COMPARTMENTS SYSTEM VALID LBACSYS OLS$USER_GROUPS SYSTEM VALID LBACSYS OLS$PROFILES SYSTEM VALID LBACSYS OLS$DIP_DEBUG SYSTEM VALID LBACSYS OLS$DIP_EVENTS SYSTEM VALID LBACSYS OLS$AUDIT SYSTEM VALID LBACSYS OLS$AUDIT_ACTIONS SYSTEM VALID SYS DBMS_SQLPATCH_STATE SYSTEM VALID SYS DBMS_SQLPATCH_FILES SYSTEM VALID SYS AQ_SRVNTFN_TABLE_1 SYSTEM VALID OWNER TABLE_NAME TABLESPACE_NAME STATUS --------------- ------------------------------ -------------------- ---------- SYS REGISTRY$SQLPATCH_RU_INFO SYSTEM VALID 已选择 912 行。 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'basic')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ SELECT OWNER,TABLE_NAME,TABLESPACE_NAME,STATUS FROM TEST_ENV.TB_TABLE_LIST WHERE TABLESPACE_NAME='SYSTEM' Plan hash value: 4282437356 ----------------------------------------------------------------------------- | Id | Operation | Name | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------- | 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 2 | BITMAP CONVERSION TO ROWIDS | | | 3 | BITMAP INDEX SINGLE VALUE | BIDX_TB_TABLE_LIST_TABLESPACE | ----------------------------------------------------------------------------- 已选择 16 行。
Bitmap Index Range Scans
当谓词条件在bitmap索引列上是一个范围值的时候，如Bitmap Conversion to Rowid中的例子，它在执行计划中表现为BITMAP INDEX RANGE SCAN关键字。
Bitmap Merge
此访问路径合并多个Bitmap，并返回单个Bitmap做为结果。在执行计划中表现为BITMAP MERGE关键字
SQL> select owner,table_name,status,ini_trans from test_env.tb_table_list where ini_trans>=4 and tablespace_name='SYSTEM'; OWNER TABLE_NAME STATUS INI_TRANS --------------- ------------------------------ ---------- ---------- SYS OBJECT_USAGE VALID 30 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'basic')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ EXPLAINED SQL STATEMENT: ------------------------ select owner,table_name,status,ini_trans from test_env.tb_table_list where ini_trans>=4 and tablespace_name='SYSTEM' Plan hash value: 1400915856 ----------------------------------------------------------------------------- | Id | Operation | Name | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ | 1 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 2 | BITMAP CONVERSION TO ROWIDS | | | 3 | BITMAP AND | | | 4 | BITMAP INDEX SINGLE VALUE | BIDX_TB_TABLE_LIST_TABLESPACE | | 5 | BITMAP MERGE | | | 6 | BITMAP INDEX RANGE SCAN | BIDX_TB_TABLE_LIST_INITRANS | ----------------------------------------------------------------------------- 已选择 19 行。
表链接相关
在进行多表关联查询的时候，优化器须要考虑如下内容：
- 数据访问方式 同单表查询同样，优化器必须选择是全表扫描仍是经过索引来检索表中数据
- 关联方法 即如何对表进行关联。可能的关联方式有，hash join,nested loops,sorted merge。
- 关联类型 关联条件决定了关联的类型，如inner join，outer join等
- 关联的顺序 在进行表关联的时候，优化器须要决定先关联哪些表，哪一个表做为驱动表。基本思想就是尽快的过滤掉尽量多的数据。
Nested Loops Joins
嵌套循环链接，能够理解为一个嵌套的for循环，经过外部表的每一条数据去匹配内部表的数据：
FOR erow IN outer_table LOOP
FOR drow IN inner_table LOOP
return match value
END LOOP
END LOOP
嵌套循环链接适用于如下状况：
- 数据集很小的时候
- 在FIRST_ROW的优化器模式下关联大表
- 关联条件能够高效的访问内部表
通常状况下，只有在数据集比较小而且关联条件存在索引的时候会使用该方式。也能够经过加入如下hints的方式来强制走嵌套训话链接。：
- USE_NL_WITH_INDEX(table index) 由优化器决定那个表做为驱动表，index是可选的，不指定则由优化器决定
- ORDERED USE_NL(d) 指定内部表
SQL> select /*+ORDERED USE_NL(B) */A.owner,A.table_name,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B WHERE A.TABLE_NAME=B.TABLE_NAME AND B.TABLE_NAME='ACCESS$'; OWNER TABLE_NAME COLUMN_NAME --------------- ------------------------------ -------------------- SYS ACCESS$ D_OBJ# SYS ACCESS$ ORDER# SYS ACCESS$ COLUMNS SYS ACCESS$ TYPES SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'basic')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ EXPLAINED SQL STATEMENT: ------------------------ select /*+ORDERED USE_NL(B) */A.owner,A.table_name,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B WHERE A.TABLE_NAME=B.TABLE_NAME AND B.TABLE_NAME='ACCESS$' Plan hash value: 1684280275 ---------------------------------------------------------------------- | Id | Operation | Name | ---------------------------------------------------------------------- PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | 1 | NESTED LOOPS | | | 2 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_COLUMN_LIST | | 3 | INDEX RANGE SCAN | TB_COLUMN_LIST_TBNAME | | 4 | INDEX RANGE SCAN | TB_TABLE_LIST_TBNAME | ---------------------------------------------------------------------- 已选择 18 行。
Hash Joins
这是大数据集关联的常见方式，也是咱们平常见得最多的关联方式。优化器会选择两个数据集中较小的一个表，而后用关联字段来构建hash表，存放在PGA中(若是PGA大小不够存放该hash表，则会将部分数据放入到临时表中)，而后，数据库扫描较大的数据集，探测哈希表以查找知足链接条件的数据行。 赞成经过USE_HASH的hints来强制数据库走HASH链接。
SQL> select /*+USE_HASH(A B) */A.owner,A.table_name,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B WHERE A.TABLE_NAME=B.TABLE_NAME AND A.OWNER=B.OWNER AND B.TABLE_NAME='ACCESS$'; OWNER TABLE_NAME COLUMN_NAME --------------- ------------------------------ -------------------- SYS ACCESS$ D_OBJ# SYS ACCESS$ ORDER# SYS ACCESS$ COLUMNS SYS ACCESS$ TYPES SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'basic')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ EXPLAINED SQL STATEMENT: ------------------------ select /*+USE_HASH(A B) */A.owner,A.table_name,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B WHERE A.TABLE_NAME=B.TABLE_NAME AND A.OWNER=B.OWNER AND B.TABLE_NAME='ACCESS$' Plan hash value: 209128112 ---------------------------------------------------------------------- | Id | Operation | Name | ---------------------------------------------------------------------- PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | 1 | HASH JOIN | | | 2 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 3 | INDEX RANGE SCAN | TB_TABLE_LIST_TBNAME | | 4 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_COLUMN_LIST | | 5 | INDEX RANGE SCAN | TB_COLUMN_LIST_TBNAME | ---------------------------------------------------------------------- 已选择 19 行。
Sorted Merge Joins
这是Nested Loops的一个变种。数据库会首先执行SORT JOIN操做对两个数据集进行排序，而后遍历外部数据集的每一行，去匹配内部数据集，第二次开始后面每次的匹配位置，取决于前一次迭代的匹配。 如下状况会选择进行Sorted Merge：
- 链接条件不是等值链接，如>,<>
- 因为其余操做须要排序，优化器发现使用排序合并成本更低。
SQL> select A.owner,A.table_name,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B WHERE A.TABLE_NAME=B.TABLE_NAME AND A.OWNER=B.OWNER AND B.TABLE_NAME='ACCESS$' ORDER BY TABLE_NAME; .... OWNER TABLE_NAME COLUMN_NAME --------------- ------------------------------ -------------------- SYS XSTREAM$_SYSGEN_OBJS SPARE5 SYS XSTREAM$_SYSGEN_OBJS SPARE4 SYS XSTREAM$_SYSGEN_OBJS SPARE3 SYS XSTREAM$_SYSGEN_OBJS SPARE2 SYS XSTREAM$_SYSGEN_OBJS SPARE6 SYS XSTREAM$_SYSGEN_OBJS OBJECT_TYPE SYS XSTREAM$_SYSGEN_OBJS OBJECT_NAME SYS XSTREAM$_SYSGEN_OBJS OBJECT_OWNER SYS XSTREAM$_SYSGEN_OBJS SERVER_NAME SYS XSTREAM$_SYSGEN_OBJS SPARE1 SYS _default_auditing_options_ A 已选择 23104 行。 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'basic')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------ EXPLAINED SQL STATEMENT: ------------------------ select A.owner,A.table_name,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B WHERE A.TABLE_NAME=B.TABLE_NAME AND A.OWNER=B.OWNER ORDER BY TABLE_NAME Plan hash value: 3270676555 --------------------------------------------------- | Id | Operation | Name | --------------------------------------------------- PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | 1 | MERGE JOIN | | | 2 | SORT JOIN | | | 3 | INDEX FAST FULL SCAN| PK_TB_TABLE_LIST | | 4 | SORT JOIN | | | 5 | TABLE ACCESS FULL | TB_COLUMN_LIST | --------------------------------------------------- 已选择 19 行。
查询转换相关
咱们发送给ORACLE的目标SQL与最终执行的SQL有多是不一样的，oracle有可能执行一系列查询转换的操做(如视图合并，子查询展开等)将SQL改写成语义等价的其余形式，是否执行查询转换取决于ORACLE对转换后SQL执行效率的评估。
OR扩展
OR扩展会将OR语句改写为UNION-ALL的形式，这样各个分支各自走索引、分区修剪、表链接等互不干扰。在以前版本中使用的CONCATENATION来执行OR扩展，12.2开始采用了UNION-ALL的方式。
SQL> select A.owner,A.table_name,B.STATUS,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B 2 WHERE A.TABLE_NAME=B.TABLE_NAME AND A.OWNER=B.OWNER AND (B.TABLE_NAME='ACCESS$' OR B.OWNER='XDB'); ...... OWNER TABLE_NAME STATUS COLUMN_NAME --------------- ------------------------------ ---------- -------------------- XDB XDB_INDEX_DDL_CACHE VALID CONSTR_OWNER SYS ACCESS$ VALID TYPES SYS ACCESS$ VALID D_OBJ# SYS ACCESS$ VALID ORDER# SYS ACCESS$ VALID COLUMNS 已选择 170 行。 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'BASIC')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ EXPLAINED SQL STATEMENT: ------------------------ select A.owner,A.table_name,B.STATUS,A.column_name from TEST_ENV.TB_COLUMN_LIST A,TEST_ENV.TB_TABLE_LIST B WHERE A.TABLE_NAME=B.TABLE_NAME AND A.OWNER=B.OWNER AND (B.TABLE_NAME='ACCESS$' OR B.OWNER='XDB') Plan hash value: 1155047104 ------------------------------------------------------------------------- | Id | Operation | Name | PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | NESTED LOOPS | | | 2 | NESTED LOOPS | | | 3 | VIEW | VW_JF_SET$ADB40ABC | | 4 | UNION-ALL | | | 5 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 6 | INDEX RANGE SCAN | PK_TB_TABLE_LIST | | 7 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 8 | INDEX RANGE SCAN | TB_TABLE_LIST_TBNAME | | 9 | INDEX RANGE SCAN | TB_COLUMN_LIST_TBNAME | PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ | 10 | TABLE ACCESS BY INDEX ROWID | TB_COLUMN_LIST | ------------------------------------------------------------------------- 已选择 25 行。
视图合并
将视图合并到包含它的查询块中。进行试图合并后优化器能够考虑更多的链接顺序、访问方式和其余的查询转换，以此来获取更好的性能。视图合并又分为简单视图合并和复杂视图合并。 1.简单视图合并 对于简单试图，视图合并老是会带来更好的执行计划，因此数据库老是会进行合并而不会考虑成本。 存在如下状况时不会进行简单视图合并：
- 视图中包含如下结构时：GROUP BY,DISTINCT,OUTER JOIN, MODEL, CONNECT BY, 集合操做, 聚合
- 视图出如今半链接或者反链接右侧时
- 视图出如今SELECT中的子查询
- 外部查询块包含PL/SQL函数
下面是一个执行了视图合并的例子：
SQL> select A.owner,A.table_name,V_B.STATUS,A.column_name from TEST_ENV.TB_COLUMN_LIST A,
(SELECT OWNER,TABLE_NAME,STATUS FROM TEST_ENV.TB_TABLE_LIST) V_B
WHERE A.TABLE_NAME=V_B.TABLE_NAME AND A.OWNER=V_B.OWNER;
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'BASIC'))
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------
EXPLAINED SQL STATEMENT:
------------------------
select A.owner,A.table_name,V_B.STATUS,A.column_name from
TEST_ENV.TB_COLUMN_LIST A, (SELECT OWNER,TABLE_NAME,STATUS FROM
TEST_ENV.TB_TABLE_LIST) V_B WHERE A.TABLE_NAME=V_B.TABLE_NAME AND
A.OWNER=V_B.OWNER
Plan hash value: 4162551876
---------------------------------------------
| Id | Operation | Name |
---------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | HASH JOIN | |
| 2 | TABLE ACCESS FULL| TB_TABLE_LIST |
| 3 | TABLE ACCESS FULL| TB_COLUMN_LIST |
---------------------------------------------
已选择 18 行。
而后加个no_merge的hint取消视图合并，对比下执行计划。
SQL> select A.owner,A.table_name,V_B.STATUS,A.column_name from TEST_ENV.TB_COLUMN_LIST A,
(SELECT /*+no_merge*/OWNER,TABLE_NAME,STATUS FROM TEST_ENV.TB_TABLE_LIST) V_B
WHERE A.TABLE_NAME=V_B.TABLE_NAME AND A.OWNER=V_B.OWNER;
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic'));
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------
EXPLAINED SQL STATEMENT:
------------------------
select A.owner,A.table_name,V_B.STATUS,A.column_name from
TEST_ENV.TB_COLUMN_LIST A, (SELECT /*+no_merge*/OWNER,TABLE_NAME,STATUS
FROM TEST_ENV.TB_TABLE_LIST) V_B WHERE A.TABLE_NAME=V_B.TABLE_NAME AND
A.OWNER=V_B.OWNER
Plan hash value: 3859876297
----------------------------------------------
| Id | Operation | Name |
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------
----------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | HASH JOIN | |
| 2 | VIEW | |
| 3 | TABLE ACCESS FULL| TB_TABLE_LIST |
| 4 | TABLE ACCESS FULL | TB_COLUMN_LIST |
----------------------------------------------
已选择 19 行。
能够看到第二个执行计划出现了view关键字，表示会把V_B这个视图进行单独的处理。
2.复杂视图合并 复杂视图合并会合并包含GROUP BY和DISTINCT操做的视图，优化器会把GROUP BY和DISTINCT操做延迟到链接以后。是否进行复杂视图合并，取决于优化器对合并后性能的评估。抛开成本问题，如下状况不会进行复杂视图合并：
- 外部查询表没有rowid或者unique column
- 视图出如今CONNECT BY查询中
- 视图包含 GROUPING SETS, ROLLUP, 或PIVOT
- 视图或者外部查询包含MODEL
SQL> (SELECT OWNER,TABLE_NAME,COUNT(*) AS CNT_COLS FROM TEST_ENV.TB_COLUMN_LIST GROUP BY OWNER,TABLE_NAME) V_A, 2 TEST_ENV.TB_TABLE_LIST B 3 WHERE V_A.TABLE_NAME=B.TABLE_NAME AND V_A.OWNER=B.OWNER AND B.OWNER='XDB'; SQL> select * from table(dbms_xplan.display_cursor(null, null, 'basic')); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ SELECT B.OWNER,B.TABLE_NAME,B.TABLESPACE_NAME,B.STATUS,V_A.CNT_COLS FROM (SELECT A.OWNER,A.TABLE_NAME,COUNT(*) AS CNT_COLS FROM TEST_ENV.TB_COLUMN_LIST A GROUP BY A.OWNER,A.TABLE_NAME) V_A, TEST_ENV.TB_TABLE_LIST B WHERE V_A.TABLE_NAME=B.TABLE_NAME AND V_A.OWNER=B.OWNER AND B.OWNER='XDB' Plan hash value: 3165065995 ------------------------------------------------------------------------ PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------- | Id | Operation | Name | ------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | 1 | HASH GROUP BY | | | 2 | NESTED LOOPS | | | 3 | NESTED LOOPS | | | 4 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_TABLE_LIST | | 5 | INDEX RANGE SCAN | PK_TB_TABLE_LIST | | 6 | INDEX RANGE SCAN | TB_COLUMN_LIST_TBNAME | | 7 | TABLE ACCESS BY INDEX ROWID | TB_COLUMN_LIST | ------------------------------------------------------------------------ PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------- 已选择 23 行。
能够看到执行计划中已经没有VIEW关键字了，而且GROUP BY操做延迟到了嵌套循环链接以后。
谓词推入
优化器处理带视图的目标SQL的另外一种优化手段。数据库能够将推入的谓词来访问索引或者做为过滤条件，进而走基于索引的嵌套循环链接。 仍是上面的列子，如今加一个no_merger的hint，避免作视图合并。VIEW PUSHED PREDICATE代表此时作的是谓词推入。
SQL> SELECT B.OWNER,B.TABLE_NAME,B.TABLESPACE_NAME,B.STATUS,V_A.CNT_COLS FROM (SELECT /*+no_merge*/A.OWNER,A.TABLE_NAME,COUNT(*) AS CNT_COLS FROM TEST_ENV.TB_COLUMN_LIST A GROUP BY A.OWNER,A.TABLE_NAME) V_A, TEST_ENV.TB_TABLE_LIST B WHERE V_A.TABLE_NAME=B.TABLE_NAME AND V_A.OWNER=B.OWNER AND B.OWNER='XDB'; SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'BASIC')); PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ SELECT B.OWNER,B.TABLE_NAME,B.TABLESPACE_NAME,B.STATUS,V_A.CNT_COLS FROM (SELECT /*+no_merge*/A.OWNER,A.TABLE_NAME,COUNT(*) AS CNT_COLS FROM TEST_ENV.TB_COLUMN_LIST A GROUP BY A.OWNER,A.TABLE_NAME) V_A, TEST_ENV.TB_TABLE_LIST B WHERE V_A.TABLE_NAME=B.TABLE_NAME AND V_A.OWNER=B.OWNER AND B.OWNER='XDB' Plan hash value: 466935718 ------------------------------------------------------------------------ PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------- | Id | Operation | Name | ------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | 1 | NESTED LOOPS | | | 2 | TABLE ACCESS BY INDEX ROWID BATCHED | TB_TABLE_LIST | | 3 | INDEX RANGE SCAN | PK_TB_TABLE_LIST | | 4 | VIEW PUSHED PREDICATE | | | 5 | SORT GROUP BY | | | 6 | TABLE ACCESS BY INDEX ROWID BATCHED| TB_COLUMN_LIST | | 7 | INDEX RANGE SCAN | TB_COLUMN_LIST_TBNAME | ------------------------------------------------------------------------ PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------- 已选择 23 行。
子查询展开
在子查询展开中优化器会把嵌套的子查询转换成一个关联查询语句。只有当JOIN语句返回的数据行与原始SQL返回数据行相同，而且子查询中不包含聚合函数(如AVG)时，优化器才会执行此转换。
SQL> SELECT OWNER,TABLE_NAME,COLUMN_NAME FROM TEST_ENV.TB_TABLE_LIST WHERE 2 (OWNER,TABLE_NAME) IN (SELECT OWNER, TABLE_NAME FROM TEST_ENV.TB_TABLE_LIST); SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'BASIC')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ SELECT OWNER,TABLE_NAME,COLUMN_NAME FROM TEST_ENV.TB_COLUMN_LIST WHERE (OWNER,TABLE_NAME) IN (SELECT OWNER, TABLE_NAME FROM TEST_ENV.TB_TABLE_LIST) Plan hash value: 2699376560 -------------------------------------------------- | Id | Operation | Name | -------------------------------------------------- PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | HASH JOIN | | | 2 | INDEX FAST FULL SCAN| PK_TB_TABLE_LIST | | 3 | TABLE ACCESS FULL | TB_COLUMN_LIST | -------------------------------------------------- 已选择 17 行。
从上面的执行计划能够看出，执行子查询展开后，表现为两个表进行HASH JOIN。咱们可使用no_unnest的hint来让优化器不对该SQL执行子查询展开。此时的执行计划以下：
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'BASIC')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- EXPLAINED SQL STATEMENT: ------------------------ select owner,table_name,column_name from test_env.tb_column_list where (owner,table_name) in(select /*+no_unnest*/ owner,table_name from test_env.tb_table_list) Plan hash value: 2714665686 ----------------------------------------------- | Id | Operation | Name | ----------------------------------------------- PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | FILTER | | | 2 | TABLE ACCESS FULL| TB_COLUMN_LIST | | 3 | INDEX UNIQUE SCAN| PK_TB_TABLE_LIST | ----------------------------------------------- 已选择 17 行。
不进行子查询展开后的执行计划走的是FILTER的类型的过滤了。
表扩展
基于索引能够提升查询的性能，可是维护索引也会产生开销。在一个大的分区表中（特别是采用业务时间作PARTITION KEY的分区表），常常DML操做比较频繁的就几个分区，其余分区大多数时候都作的全表检索的时间比较多。在相似这种场景下咱们就能够只在比较活跃的分区上面建立索引，而其余分区则不建立。优化器会自动的帮咱们在有索引的分区上面经过索引检索数据，没有索引的分区进行全表扫描，而后再把结果进行UNION-ALL操做。 下面是ORACLE官网的一个例子：
- 表sales根据time_id进行范围分区
SELECT *
FROM sales
WHERE time_id >= TO_DATE('2000-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS')
AND prod_id = 38;
- 执行该语句获得的执行计划以下：
Plan hash value: 3087065703
--------------------------------------------------------------------------
|Id| Operation | Name |Pstart|Pstop|
--------------------------------------------------------------------------
| 0| SELECT STATEMENT | | | |
| 1| PARTITION RANGE ITERATOR | | 13 | 28 |
| 2| TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| SALES | 13 | 28 |
| 3| BITMAP CONVERSION TO ROWIDS | | | |
|*4| BITMAP INDEX SINGLE VALUE |SALES_PROD_BIX| 13 | 28 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("PROD_ID"=38)
- 而后将sales_q4_2003分区的索引禁用
ALTER INDEX sales_prod_bix MODIFY PARTITION sales_q4_2003 UNUSABLE; ALTER INDEX sales_time_bix MODIFY PARTITION sales_q4_2003 UNUSABLE;
- 此时数据库在有索引的分区采用索引检索数据，对没有索引的分区进行全表扫描。
Plan hash value: 2120767686
---------------------------------------------------------------------------
|Id| Operation | Name |Pstart|Pstop|
---------------------------------------------------------------------------
| 0| SELECT STATEMENT | | | |
| 1| VIEW | VW_TE_2 | | |
| 2| UNION-ALL | | | |
| 3| PARTITION RANGE ITERATOR | | 13| 27|
| 4| TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| SALES | 13| 27|
| 5| BITMAP CONVERSION TO ROWIDS | | | |
|*6| BITMAP INDEX SINGLE VALUE | SALES_PROD_BIX| 13| 27|
| 7| PARTITION RANGE SINGLE | | 28| 28|
|*8| TABLE ACCESS FULL | SALES | 28| 28|
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - access("PROD_ID"=38)
8 - filter("PROD_ID"=38)
经过将非活跃分区的索引删除的方式能够减小维护索引的成本，优化器会自动的帮咱们进行查询的改写，而不影响咱们本来的SQL语句。
相关文章
- 1. oracle-常见的执行计划（一）
- 2. 常见的执行计划步骤
- 3. Oracle中的执行计划
- 4. MYSQL中的执行计划
- 5. 获取SQL执行计划的常见几种方法
- 6. Mysql中 EXPLAIN (执行计划)
- 7. Navicat中Oracle执行计划
- 8. 执行计划
- 9. oracle中执行计划中的cardinality
- 10. oracle执行计划的执行顺序
- 更多相关文章...
- • MyBatis SqlSession和Mapper接口执行Sql - MyBatis教程
- • Redis主从复制的配置方法和执行过程 - Redis教程
- • 常用的分布式事务解决方案
- • C# 中 foreach 遍历的用法
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
欢迎关注本站公众号,获取更多信息
相关文章
- 1. oracle-常见的执行计划（一）
- 2. 常见的执行计划步骤
- 3. Oracle中的执行计划
- 4. MYSQL中的执行计划
- 5. 获取SQL执行计划的常见几种方法
- 6. Mysql中 EXPLAIN (执行计划)
- 7. Navicat中Oracle执行计划
- 8. 执行计划
- 9. oracle中执行计划中的cardinality
- 10. oracle执行计划的执行顺序