关于oracle索引的性能优化
2017-02-09 17:28
218 查看
使用索引是提高oracle查询的一种重要方式，索引的使用同时也是一柄双刃剑，使用不当也会导致性能问题。
索引的建立方式和查询语句的执行方式都会影响实际执行的效率。同时对索引的维护也会导致索引的性能问题。有些时候使用复合索引时，oracle查询不会自动使用索引，需要使用强制索引（当使用表别名时，强制索引的表名也要使用别名），如下：
SELECT /*+ INDEX(KSFK_APPDATA_INFO KSFK_DATAINFO_IDX) */ record_id,status,source_seq,modify_date,modify_time FROM KSFK_APPDATA_INFO where APPL_ID ='XXXXXXX'；
以下内容主要来自网络
一、Oracle表与索引的分析及索引重建；
二、索引执行的调试；
三、oracle索引执行的类型；
一、Oracle表与索引的分析及索引重建
1.分析表与索引（analyze 不会重建索引）
analyze table tablename compute statistics
等同于 analyze table tablename compute statistics for table for all indexes for all columns
for table 的统计信息存在于视图：user_tables 、all_tables、dba_tables
for all indexes 的统计信息存在于视图: user_indexes 、all_indexes、dba_indexes
for all columns 的统计信息存在于视图：user_tab_columns、all_tab_columns、dba_tab_columns
注：分析表与索引见 AnalyzeAllTable存储过程
2、一般来讲可以采用以下三种方式来手工分析索引。
analyze index idx_t validate structure：
analyze index idx_t compute statistics：
analyze index idx_t estimate statistics sample 10 percent
1）analyze index idx_t validate structure：
这段分析语句是用来分析索引的block中是否有坏块儿，那么根据分析我们可以得到索引的结构数据，这些数据会保留到
index_stats中，来判断这个索引是否需要rebuild. 需要注意的是这样的分析是不会收集索引的统计信息的。
2）validate structure有二种模式： online, offline， 一般来讲默认的方式是offline。
当以offline的模式analyze索引时，会对table加一个表级共享锁，对目前table的一些实时DMl操作会产生一定的影响。
而以online模式分析时候，则不会加任何lock，但在index_stats中是看不到任何信息的。
3）analyze index idx_t compute statistics：
用来统计索引的统计信息(全分析)，主要为CBO服务。
4）analyze index idx_t estimate statistics sample 10 percent
主要是用来指定比例进行抽样分析，也是为CBO服务. 例中是抽样10%
3.重建索引
alter index index_name rebuild tablespace tablespace_name
alter index index_name rebuild tablespace tablespace_name 加入表空间名，会将指定的索引移动到指定的表空间当中。
注：
analyze 操作只是统计信息，并将统计信息存放起来供日后分析SQL使用，不进行重建之类的具体实施性操作,因此要重建索引的话
还是要用 alter index index_name rebuild
4、其他的统计方法
1）DBMS_STATS：这个当然是最强大的分析包了
--创建统计信息历史保留表
exec dbms_stats.create_stat_table(ownname => 'scott',stattab => 'stat_table');
--导出整个scheme的统计信息
exec dbms_stats.export_schema_stats(ownname => 'scott',stattab => 'stat_table');
--分析scheme
Exec dbms_stats.gather_schema_stats(ownname => 'test',options => 'GATHER AUTO',
estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'for all indexed columns',
degree => 6 );
--分析表
exec dbms_stats.gather_table_stats(ownname => 'TEST',tabname => 'sm_user',estimate_percent => 10,method_opt=> 'for all indexed columns') ;
--分析索引
exec dbms_stats.gather_index_stats(ownname => 'TEST',indname => 'pk_user_index',estimate_percent => '10',degree => '4') ;
--如果发现执行计划走错，删除表的统计信息
exec dbms_stats.delete_table_stats(ownname => 'TEST',tabname => 'SM_USER') ;
--导入表的历史统计信息
exec dbms_stats.import_table_stats(ownname => 'TEST',tabname => 'SM_USER',stattab => 'stat_table') ;
--如果进行分析后，大部分表的执行计划都走错，需要导回整个scheme的统计信息
exec dbms_stats.import_schema_stats(ownname => 'TEST',stattab => 'SM_USER');
--导入索引的统计信息
exec dbms_stats.import_index_stats(ownname => 'TEST',indname => 'PK_USER_INDEX',stattab => 'stat_table')
analyze和dbms_stats不同的地方:
analyze是同时更新表和索引的统计信息，而dbms_stats会先更新表的统计信息，然后再更新索引的统计信息，
这里就有一个问题，就是当表的统计信息更新后，而索引的统计信息没有被更新，这时候cbo就有可能选择错误的plan
2）DBMS_UTILITY.ANALYZE_SCHEMA：可直接分析SCHEMA中所有对象
如：EXEC DBMS_UTILITY.ANALYZE_SCHEMA ('LTTFM','COMPUTE');
3）DBMS_DDL.ANALYZE_OBJECT：收集对象的的统计信息
二、索引执行的调试--查看oracle查询执行计划；
使用toad和plsql工具可以查看oracle查询的执行计划，也可以直接使用命令，命令如下：
SQL> explain plan for SELECT /*+ INDEX(a KSFK_DATAINFO_IDX) */ appl_id,custr_nbr,a.* FROM MCAM.KSFK_APPDATA_INFO a where a.CUSTR_NBR='142724198909251433';
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1289526622
--------------------------------------------------------------------------------
-----------------
| Id | Operation | Name| Rows
| Bytes | Cost (
%CPU)| Time |
--------------------------------------------------------------------------------
-----------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT || 1 | 564 | 5
(0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| KSFK_APPDATA_INFO | 1 | 564 | 5
(0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | KSFK_DATAINFO_IDX | 1 || 3
(0)| 00:00:01 |
--------------------------------------------------------------------------------
-----------------
PLAN_TABLE_OUTPUT
---------------------------------------------------------
4000
-----------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("A"."CUSTR_NBR"='142724198909251433')
三、oracle查询执行索引的类型；
Oracle 索引扫描的五种类型
标签： oracleobjecttableaccesssqlfilter
2010-08-31 11:06 17217人阅读 评论(5) 收藏 举报
分类： Oracle Performance（81） Oracle Advanced Knowledge（186）
版权声明：本文为博主原创文章，未经博主允许不得转载。
之前在讨论CBO和RBO的时候提到了索引扫描的几种类型。
Oracle Optimizer CBO RBO
http://blog.csdn.net/tianlesoftware/archive/2010/08/19/5824886.aspx
Oracle 索引 详解
http://blog.csdn.net/tianlesoftware/archive/2010/03/05/5347098.aspx
Oracle Explain Plan
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5827245.aspx
根据索引的类型与where限制条件的不同，有4种类型的Oracle索引扫描：
（1） 索引唯一扫描(index unique scan)
（2） 索引范围扫描(index range scan)
（3） 索引全扫描(index full scan)
（4） 索引快速扫描(index fast full scan)
（5） 索引跳跃扫描（INDEX SKIP SCAN）
一. 索引唯一扫描(index unique scan)
通过唯一索引查找一个数值经常返回单个ROWID。如果该唯一索引有多个列组成(即组合索引)，则至少要有组合索引的引导列参与到该查询中，如创建一个索引：create index idx_test on emp(ename, deptno, loc)。则select ename from emp where ename = ‘JACK’ and deptno = ‘DEV’语句可以使用该索引。如果该语句只返回一行，则存取方法称为索引唯一扫描。而select ename from emp where deptno =
‘DEV’语句则不会使用该索引，因为where子句种没有引导列。如果存在UNIQUE 或PRIMARY KEY 约束(它保证了语句只存取单行)的话，Oracle经常实现唯一性扫描。
如：
SQL> set autot traceonly exp; -- 只显示执行计划
SQL> select * from scott.emp t where t.empno=10;
执行计划
----------------------------------------------------------
Plan hash value: 2949544139
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 38 | 1 (0)| 00:0
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 38 | 1 (0)| 00:0
|* 2 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 0 (0)| 00:0
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("T"."EMPNO"=10)
二．索引范围扫描(index range scan)
使用一个索引存取多行数据，同上面一样，如果索引是组合索引，而且select ename from emp where ename = ‘JACK’ and deptno = ‘DEV’语句返回多行数据，虽然该语句还是使用该组合索引进行查询，可此时的存取方法称为索引范围扫描。
在唯一索引上使用索引范围扫描的典型情况下是在谓词(where限制条件)中使用了范围操作符(如>、<、<>、>=、<=、between)
使用索引范围扫描的例子：
SQL> select empno,ename from scott.emp where empno > 7876 order by empno;
执行计划
----------------------------------------------------------
Plan hash value: 169057108
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 10 | 2 (0)| 00:0
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 10 | 2 (0)| 00:0
|* 2 | INDEX RANGE SCAN | PK_EMP | 1 | | 1 (0)| 00:0
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("EMPNO">7876)
在非唯一索引上，谓词可能返回多行数据，所以在非唯一索引上都使用索引范围扫描。
使用index rang scan的3种情况：
(a) 在唯一索引列上使用了range操作符(> < <> >= <= between)。
(b) 在组合索引上，只使用部分列进行查询，导致查询出多行。
(c) 对非唯一索引列上进行的任何查询。
三．索引全扫描(index full scan)
与全表扫描对应，也有相应的全Oracle索引扫描。在某些情况下，可能进行全Oracle索引扫描而不是范围扫描，需要注意的是全Oracle索引扫描只在CBO模式下才有效。 CBO根据统计数值得知进行全Oracle索引扫描比进行全表扫描更有效时，才进行全Oracle索引扫描，而且此时查询出的数据都必须从索引中可以直接得到。
全Oracle索引扫描的例子：
SQL> create index big_emp on scott.emp(empno,ename);
索引已创建。
SQL> select empno, ename from scott.emp order by empno,ename;
执行计划
----------------------------------------------------------
Plan hash value: 322359667
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 14 | 140 | 1 (0)| 00:00:01 |
| 1 | INDEX FULL SCAN | BIG_EMP | 14 | 140 | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------
四． 索引快速扫描(index fast full scan)
扫描索引中的所有的数据块，与 index full scan很类似，但是一个显著的区别就是它不对查询出的数据进行排序，即数据不是以排序顺序被返回。在这种存取方法中，可以使用多块读功能，也可以使用并行读入，以便获得最大吞吐量与缩短执行时间。
索引快速扫描的例子：
SQL> select /*+ index_ffs(dave index_dave) */ id from dave where id>0;
执行计划
----------------------------------------------------------
Plan hash value: 674200218
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 | 24 | 2 (0)| 00:00:0
|* 1 | INDEX FAST FULL SCAN| INDEX_DAVE | 8 | 24 | 2 (0)| 00:00:0
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID">0)
为了实现这个效果，折腾了半天，最终还是用hint来了.
Oracle Hint
http://blog.csdn.net/tianlesoftware/archive/2010/03/05/5347098.aspx
五. 索引跳跃扫描（INDEX SKIP SCAN）
INDEX SKIP SCAN，发生在多个列建立的复合索引上，如果SQL中谓词条件只包含索引中的部分列，并且这些列不是建立索引时的第一列时，就可能发生INDEX SKIP SCAN。这里SKIP的意思是因为查询条件没有第一列或前面几列，被忽略了。
Oracle 10g的文档如下：
Index skip scans improve index scans by nonprefix columns. Often, scanning index blocks is faster than scanning table data blocks.
Skip scanning lets a composite index be split logically into smaller subindexes. In skip scanning, the initial column of the composite index is not specified in the query. In other words, it is skipped.
--skip scan 让组合索引（composite index）逻辑的split 成几个子索引。如果在在查询时，第一个列没有指定，就跳过它。
The number of logical subindexes is determined by the number of distinct values in the initial column. Skip scanning is advantageous if there are few distinct values in the leading column of the composite index and many distinct values in the nonleading
key of the index.
-- 建议将distinct 值小的列作为组合索引的引导列，即第一列。
Example 13-5 Index Skip Scan
Consider, for example, a table employees (sex, employee_id, address) with a composite index on (sex, employee_id). Splitting this composite index would result in two logical subindexes, one for M and one for F.
For this example, suppose you have the following index data:
('F',98)
('F',100)
('F',102)
('F',104)
('M',101)
('M',103)
('M',105)
The index is split logically into the following two subindexes:
（1）The first subindex has the keys with the value F.
（2）The second subindex has the keys with the value M.
Figure 13-2 Index Skip Scan Illustration
The column sex is skipped in the following query:
SELECT *
FROM employees
WHERE employee_id = 101;
A complete scan of the index is not performed, but the subindex with the value F is searched first, followed by a search of the subindex with the value M.
测试：
创建表：
SQL> create table dave_test as select owner,object_id,object_type,created from dba_objects;
Table created.
创建组合索引
SQL> create index idx_dave_test_com on dave_test(owner,object_id,object_type);
Index created.
--收集表的统计信息
SQL> exec dbms_stats.gather_table_stats('SYS','DAVE_TEST');
PL/SQL procedure successfully completed.
SQL> set autot traceonly exp;
指定组合索引的所有字段时，使用Index range scan：
SQL> select * from dave_test where owner='SYS' and object_id=20 and object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 418973243
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 2
| 1 | TABLE ACCESS BY INDEX ROWID| DAVE_TEST | 1 | 27 | 2
|* 2 | INDEX RANGE SCAN | IDX_DAVE_TEST_COM | 1 | | 1
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OWNER"='SYS' AND "OBJECT_ID"=20 AND "OBJECT_TYPE"='TABLE')
指定组合索引的2个字段时，使用的还是index range scan：
SQL> select * from dave_test where owner='SYS' and object_id=20;
Execution Plan
----------------------------------------------------------
Plan hash value: 418973243
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 3
| 1 | TABLE ACCESS BY INDEX ROWID| DAVE_TEST | 1 | 27 | 3
|* 2 | INDEX RANGE SCAN | IDX_DAVE_TEST_COM | 1 | | 2
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OWNER"='SYS' AND "OBJECT_ID"=20)
指定组合索引的引导列，即第一个列时，不走索引，走全表扫描
SQL> select * from dave_test where owner='SYS';
Execution Plan
----------------------------------------------------------
Plan hash value: 1539627441
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 23567 | 621K| 52 (4)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DAVE_TEST | 23567 | 621K| 52 (4)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OWNER"='SYS')
指定组合索引的非引导列，使用Index skip scan：
SQL> select * from dave_test where object_id=20 and object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 3446962311
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 22
| 1 | TABLE ACCESS BY INDEX ROWID| DAVE_TEST | 1 | 27 | 22
|* 2 | INDEX SKIP SCAN | IDX_DAVE_TEST_COM | 1 | | 21
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OBJECT_ID"=20 AND "OBJECT_TYPE"='TABLE')
filter("OBJECT_ID"=20 AND "OBJECT_TYPE"='TABLE')
指定组合索引的最后一列，不走索引，走全表扫描
SQL> select * from dave_test where object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 1539627441
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------
b1b3
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1774 | 47898 | 52 (4)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DAVE_TEST | 1774 | 47898 | 52 (4)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OBJECT_TYPE"='TABLE')
指定组合索引的头尾2列，不走索引：
SQL> select * from dave_test where owner='SYS' and object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 1539627441
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 830 | 22410 | 52 (4)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DAVE_TEST | 830 | 22410 | 52 (4)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OBJECT_TYPE"='TABLE' AND "OWNER"='SYS')
通过以上测试，和之前官网的说明，Index skip scan 仅是在组合索引的引导列，即第一列没有指定，并且非引导列指定的情况下。
联合索引选择性更高咯，所占空间应当是比单独索引要少，因为叶节点节省了重复的rowid，当然branch节点可能稍微多一点。
禁用skip scan:
alter system set “_optimizer_skip_scan_enabled” = false scope=spfile;
索引的建立方式和查询语句的执行方式都会影响实际执行的效率。同时对索引的维护也会导致索引的性能问题。有些时候使用复合索引时，oracle查询不会自动使用索引，需要使用强制索引（当使用表别名时，强制索引的表名也要使用别名），如下：
SELECT /*+ INDEX(KSFK_APPDATA_INFO KSFK_DATAINFO_IDX) */ record_id,status,source_seq,modify_date,modify_time FROM KSFK_APPDATA_INFO where APPL_ID ='XXXXXXX'；
以下内容主要来自网络
一、Oracle表与索引的分析及索引重建；
二、索引执行的调试；
三、oracle索引执行的类型；
一、Oracle表与索引的分析及索引重建
1.分析表与索引（analyze 不会重建索引）
analyze table tablename compute statistics
等同于 analyze table tablename compute statistics for table for all indexes for all columns
for table 的统计信息存在于视图：user_tables 、all_tables、dba_tables
for all indexes 的统计信息存在于视图: user_indexes 、all_indexes、dba_indexes
for all columns 的统计信息存在于视图：user_tab_columns、all_tab_columns、dba_tab_columns
注：分析表与索引见 AnalyzeAllTable存储过程
2、一般来讲可以采用以下三种方式来手工分析索引。
analyze index idx_t validate structure：
analyze index idx_t compute statistics：
analyze index idx_t estimate statistics sample 10 percent
1）analyze index idx_t validate structure：
这段分析语句是用来分析索引的block中是否有坏块儿，那么根据分析我们可以得到索引的结构数据，这些数据会保留到
index_stats中，来判断这个索引是否需要rebuild. 需要注意的是这样的分析是不会收集索引的统计信息的。
2）validate structure有二种模式： online, offline， 一般来讲默认的方式是offline。
当以offline的模式analyze索引时，会对table加一个表级共享锁，对目前table的一些实时DMl操作会产生一定的影响。
而以online模式分析时候，则不会加任何lock，但在index_stats中是看不到任何信息的。
3）analyze index idx_t compute statistics：
用来统计索引的统计信息(全分析)，主要为CBO服务。
4）analyze index idx_t estimate statistics sample 10 percent
主要是用来指定比例进行抽样分析，也是为CBO服务. 例中是抽样10%
3.重建索引
alter index index_name rebuild tablespace tablespace_name
alter index index_name rebuild tablespace tablespace_name 加入表空间名，会将指定的索引移动到指定的表空间当中。
注：
analyze 操作只是统计信息，并将统计信息存放起来供日后分析SQL使用，不进行重建之类的具体实施性操作,因此要重建索引的话
还是要用 alter index index_name rebuild
4、其他的统计方法
1）DBMS_STATS：这个当然是最强大的分析包了
--创建统计信息历史保留表
exec dbms_stats.create_stat_table(ownname => 'scott',stattab => 'stat_table');
--导出整个scheme的统计信息
exec dbms_stats.export_schema_stats(ownname => 'scott',stattab => 'stat_table');
--分析scheme
Exec dbms_stats.gather_schema_stats(ownname => 'test',options => 'GATHER AUTO',
estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'for all indexed columns',
degree => 6 );
--分析表
exec dbms_stats.gather_table_stats(ownname => 'TEST',tabname => 'sm_user',estimate_percent => 10,method_opt=> 'for all indexed columns') ;
--分析索引
exec dbms_stats.gather_index_stats(ownname => 'TEST',indname => 'pk_user_index',estimate_percent => '10',degree => '4') ;
--如果发现执行计划走错，删除表的统计信息
exec dbms_stats.delete_table_stats(ownname => 'TEST',tabname => 'SM_USER') ;
--导入表的历史统计信息
exec dbms_stats.import_table_stats(ownname => 'TEST',tabname => 'SM_USER',stattab => 'stat_table') ;
--如果进行分析后，大部分表的执行计划都走错，需要导回整个scheme的统计信息
exec dbms_stats.import_schema_stats(ownname => 'TEST',stattab => 'SM_USER');
--导入索引的统计信息
exec dbms_stats.import_index_stats(ownname => 'TEST',indname => 'PK_USER_INDEX',stattab => 'stat_table')
analyze和dbms_stats不同的地方:
analyze是同时更新表和索引的统计信息，而dbms_stats会先更新表的统计信息，然后再更新索引的统计信息，
这里就有一个问题，就是当表的统计信息更新后，而索引的统计信息没有被更新，这时候cbo就有可能选择错误的plan
2）DBMS_UTILITY.ANALYZE_SCHEMA：可直接分析SCHEMA中所有对象
如：EXEC DBMS_UTILITY.ANALYZE_SCHEMA ('LTTFM','COMPUTE');
3）DBMS_DDL.ANALYZE_OBJECT：收集对象的的统计信息
二、索引执行的调试--查看oracle查询执行计划；
使用toad和plsql工具可以查看oracle查询的执行计划，也可以直接使用命令，命令如下：
SQL> explain plan for SELECT /*+ INDEX(a KSFK_DATAINFO_IDX) */ appl_id,custr_nbr,a.* FROM MCAM.KSFK_APPDATA_INFO a where a.CUSTR_NBR='142724198909251433';
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1289526622
--------------------------------------------------------------------------------
-----------------
| Id | Operation | Name| Rows
| Bytes | Cost (
%CPU)| Time |
--------------------------------------------------------------------------------
-----------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT || 1 | 564 | 5
(0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| KSFK_APPDATA_INFO | 1 | 564 | 5
(0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | KSFK_DATAINFO_IDX | 1 || 3
(0)| 00:00:01 |
--------------------------------------------------------------------------------
-----------------
PLAN_TABLE_OUTPUT
---------------------------------------------------------
4000
-----------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("A"."CUSTR_NBR"='142724198909251433')
三、oracle查询执行索引的类型；
Oracle 索引扫描的五种类型
标签： oracleobjecttableaccesssqlfilter
2010-08-31 11:06 17217人阅读 评论(5) 收藏 举报
分类： Oracle Performance（81） Oracle Advanced Knowledge（186）
版权声明：本文为博主原创文章，未经博主允许不得转载。
之前在讨论CBO和RBO的时候提到了索引扫描的几种类型。
Oracle Optimizer CBO RBO
http://blog.csdn.net/tianlesoftware/archive/2010/08/19/5824886.aspx
Oracle 索引 详解
http://blog.csdn.net/tianlesoftware/archive/2010/03/05/5347098.aspx
Oracle Explain Plan
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5827245.aspx
根据索引的类型与where限制条件的不同，有4种类型的Oracle索引扫描：
（1） 索引唯一扫描(index unique scan)
（2） 索引范围扫描(index range scan)
（3） 索引全扫描(index full scan)
（4） 索引快速扫描(index fast full scan)
（5） 索引跳跃扫描（INDEX SKIP SCAN）
一. 索引唯一扫描(index unique scan)
通过唯一索引查找一个数值经常返回单个ROWID。如果该唯一索引有多个列组成(即组合索引)，则至少要有组合索引的引导列参与到该查询中，如创建一个索引：create index idx_test on emp(ename, deptno, loc)。则select ename from emp where ename = ‘JACK’ and deptno = ‘DEV’语句可以使用该索引。如果该语句只返回一行，则存取方法称为索引唯一扫描。而select ename from emp where deptno =
‘DEV’语句则不会使用该索引，因为where子句种没有引导列。如果存在UNIQUE 或PRIMARY KEY 约束(它保证了语句只存取单行)的话，Oracle经常实现唯一性扫描。
如：
SQL> set autot traceonly exp; -- 只显示执行计划
SQL> select * from scott.emp t where t.empno=10;
执行计划
----------------------------------------------------------
Plan hash value: 2949544139
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 38 | 1 (0)| 00:0
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 38 | 1 (0)| 00:0
|* 2 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 0 (0)| 00:0
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("T"."EMPNO"=10)
二．索引范围扫描(index range scan)
使用一个索引存取多行数据，同上面一样，如果索引是组合索引，而且select ename from emp where ename = ‘JACK’ and deptno = ‘DEV’语句返回多行数据，虽然该语句还是使用该组合索引进行查询，可此时的存取方法称为索引范围扫描。
在唯一索引上使用索引范围扫描的典型情况下是在谓词(where限制条件)中使用了范围操作符(如>、<、<>、>=、<=、between)
使用索引范围扫描的例子：
SQL> select empno,ename from scott.emp where empno > 7876 order by empno;
执行计划
----------------------------------------------------------
Plan hash value: 169057108
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 10 | 2 (0)| 00:0
| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 10 | 2 (0)| 00:0
|* 2 | INDEX RANGE SCAN | PK_EMP | 1 | | 1 (0)| 00:0
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("EMPNO">7876)
在非唯一索引上，谓词可能返回多行数据，所以在非唯一索引上都使用索引范围扫描。
使用index rang scan的3种情况：
(a) 在唯一索引列上使用了range操作符(> < <> >= <= between)。
(b) 在组合索引上，只使用部分列进行查询，导致查询出多行。
(c) 对非唯一索引列上进行的任何查询。
三．索引全扫描(index full scan)
与全表扫描对应，也有相应的全Oracle索引扫描。在某些情况下，可能进行全Oracle索引扫描而不是范围扫描，需要注意的是全Oracle索引扫描只在CBO模式下才有效。 CBO根据统计数值得知进行全Oracle索引扫描比进行全表扫描更有效时，才进行全Oracle索引扫描，而且此时查询出的数据都必须从索引中可以直接得到。
全Oracle索引扫描的例子：
SQL> create index big_emp on scott.emp(empno,ename);
索引已创建。
SQL> select empno, ename from scott.emp order by empno,ename;
执行计划
----------------------------------------------------------
Plan hash value: 322359667
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 14 | 140 | 1 (0)| 00:00:01 |
| 1 | INDEX FULL SCAN | BIG_EMP | 14 | 140 | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------
四． 索引快速扫描(index fast full scan)
扫描索引中的所有的数据块，与 index full scan很类似，但是一个显著的区别就是它不对查询出的数据进行排序，即数据不是以排序顺序被返回。在这种存取方法中，可以使用多块读功能，也可以使用并行读入，以便获得最大吞吐量与缩短执行时间。
索引快速扫描的例子：
SQL> select /*+ index_ffs(dave index_dave) */ id from dave where id>0;
执行计划
----------------------------------------------------------
Plan hash value: 674200218
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 | 24 | 2 (0)| 00:00:0
|* 1 | INDEX FAST FULL SCAN| INDEX_DAVE | 8 | 24 | 2 (0)| 00:00:0
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID">0)
为了实现这个效果，折腾了半天，最终还是用hint来了.
Oracle Hint
http://blog.csdn.net/tianlesoftware/archive/2010/03/05/5347098.aspx
五. 索引跳跃扫描（INDEX SKIP SCAN）
INDEX SKIP SCAN，发生在多个列建立的复合索引上，如果SQL中谓词条件只包含索引中的部分列，并且这些列不是建立索引时的第一列时，就可能发生INDEX SKIP SCAN。这里SKIP的意思是因为查询条件没有第一列或前面几列，被忽略了。
Oracle 10g的文档如下：
Index skip scans improve index scans by nonprefix columns. Often, scanning index blocks is faster than scanning table data blocks.
Skip scanning lets a composite index be split logically into smaller subindexes. In skip scanning, the initial column of the composite index is not specified in the query. In other words, it is skipped.
--skip scan 让组合索引（composite index）逻辑的split 成几个子索引。如果在在查询时，第一个列没有指定，就跳过它。
The number of logical subindexes is determined by the number of distinct values in the initial column. Skip scanning is advantageous if there are few distinct values in the leading column of the composite index and many distinct values in the nonleading
key of the index.
-- 建议将distinct 值小的列作为组合索引的引导列，即第一列。
Example 13-5 Index Skip Scan
Consider, for example, a table employees (sex, employee_id, address) with a composite index on (sex, employee_id). Splitting this composite index would result in two logical subindexes, one for M and one for F.
For this example, suppose you have the following index data:
('F',98)
('F',100)
('F',102)
('F',104)
('M',101)
('M',103)
('M',105)
The index is split logically into the following two subindexes:
（1）The first subindex has the keys with the value F.
（2）The second subindex has the keys with the value M.
Figure 13-2 Index Skip Scan Illustration
The column sex is skipped in the following query:
SELECT *
FROM employees
WHERE employee_id = 101;
A complete scan of the index is not performed, but the subindex with the value F is searched first, followed by a search of the subindex with the value M.
测试：
创建表：
SQL> create table dave_test as select owner,object_id,object_type,created from dba_objects;
Table created.
创建组合索引
SQL> create index idx_dave_test_com on dave_test(owner,object_id,object_type);
Index created.
--收集表的统计信息
SQL> exec dbms_stats.gather_table_stats('SYS','DAVE_TEST');
PL/SQL procedure successfully completed.
SQL> set autot traceonly exp;
指定组合索引的所有字段时，使用Index range scan：
SQL> select * from dave_test where owner='SYS' and object_id=20 and object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 418973243
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 2
| 1 | TABLE ACCESS BY INDEX ROWID| DAVE_TEST | 1 | 27 | 2
|* 2 | INDEX RANGE SCAN | IDX_DAVE_TEST_COM | 1 | | 1
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OWNER"='SYS' AND "OBJECT_ID"=20 AND "OBJECT_TYPE"='TABLE')
指定组合索引的2个字段时，使用的还是index range scan：
SQL> select * from dave_test where owner='SYS' and object_id=20;
Execution Plan
----------------------------------------------------------
Plan hash value: 418973243
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 3
| 1 | TABLE ACCESS BY INDEX ROWID| DAVE_TEST | 1 | 27 | 3
|* 2 | INDEX RANGE SCAN | IDX_DAVE_TEST_COM | 1 | | 2
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OWNER"='SYS' AND "OBJECT_ID"=20)
指定组合索引的引导列，即第一个列时，不走索引，走全表扫描
SQL> select * from dave_test where owner='SYS';
Execution Plan
----------------------------------------------------------
Plan hash value: 1539627441
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 23567 | 621K| 52 (4)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DAVE_TEST | 23567 | 621K| 52 (4)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OWNER"='SYS')
指定组合索引的非引导列，使用Index skip scan：
SQL> select * from dave_test where object_id=20 and object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 3446962311
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 22
| 1 | TABLE ACCESS BY INDEX ROWID| DAVE_TEST | 1 | 27 | 22
|* 2 | INDEX SKIP SCAN | IDX_DAVE_TEST_COM | 1 | | 21
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OBJECT_ID"=20 AND "OBJECT_TYPE"='TABLE')
filter("OBJECT_ID"=20 AND "OBJECT_TYPE"='TABLE')
指定组合索引的最后一列，不走索引，走全表扫描
SQL> select * from dave_test where object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 1539627441
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------
b1b3
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1774 | 47898 | 52 (4)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DAVE_TEST | 1774 | 47898 | 52 (4)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OBJECT_TYPE"='TABLE')
指定组合索引的头尾2列，不走索引：
SQL> select * from dave_test where owner='SYS' and object_type='TABLE';
Execution Plan
----------------------------------------------------------
Plan hash value: 1539627441
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 830 | 22410 | 52 (4)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DAVE_TEST | 830 | 22410 | 52 (4)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("OBJECT_TYPE"='TABLE' AND "OWNER"='SYS')
通过以上测试，和之前官网的说明，Index skip scan 仅是在组合索引的引导列，即第一列没有指定，并且非引导列指定的情况下。
联合索引选择性更高咯，所占空间应当是比单独索引要少，因为叶节点节省了重复的rowid，当然branch节点可能稍微多一点。
禁用skip scan:
alter system set “_optimizer_skip_scan_enabled” = false scope=spfile;
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 关于Apache的性能优化
- 关于asp.net 性能——关于数据处理相关的优化（转）
- 关于性能优化的以及int Number uint的比较
- 关于JQuery的性能优化(转摘自-痞子刘的博客)
- 关于flash性能优化的好书
- 关于性能优化
- 【转】性能优化-关于Asp.net性能的技巧
- Java性能优化[4]：关于finalize函数
- 关于系统性能优化的一些操作和泛型的应用（第二天）
- 关于jQuery性能优化的几点建议
- 关于asp.net 性能——关于数据处理相关的优化（转）
- 关于PHP性能优化
- Asp.net性能优化总结[关于数据处理相关的优化]
- 关于性能诊断和性能优化的方法和实施案例
- 关于javascript性能优化
- 关于Servlet、Jsp性能优化
- Asp.net性能优化总结[关于数据处理相关的优化]
- 关于PHP中启用Zend Optimizer后性能优化程度的简单测试
- 关于Apache的性能优化(zt)
- 性能优化-关于JQuery的性能优化