Oracle 不使用索引的原因有哪些？

今天开始总结一下oracle不使用索引的原因有哪些。一边学习一边做笔记。聚簇因子是衡量索引列数据顺序与表字段数据顺序相似性的一

今天开始总结一下Oracle不使用索引的原因有哪些。一边学习一边做笔记。

第一种：行数存在差异。

在视图user_tables存在一个num_rows字段，该字段是记录在统计信息收集后所对应对象的行数，在user_tab_columns视图中存在一个num_distinct字段，该字段记录每个字段内不同数值的个数。oracle认为当num_distinct越接近num_rows的时候索引的选择性越好，那么在执行查询的时候越容易使用索引。

第二种：聚簇因子：

什么是聚簇因子？

聚簇因子是衡量索引列数据顺序与表字段数据顺序相似性的一个值。我们都知道在创建的表中一般都是堆表，也就是数据在表中存储是无续的，那么为了更加快速的访问数据，我们通常使用索引进行数据访问，这时候没个索引都有一个聚簇因子，聚簇因子越接近对象的块数，那么选择性越好，越接近表的行数那么选择性越差。

之前听到有个朋友曾经提到这么一个问题“为什么我在测试环境查询一个数据很快和在生产环境查询数据怎么这么慢呢？表结构都一样的，数据也是一样的。”。那么不妨看看聚簇因子是多少。

聚簇因子的查看是从user_ind_statistics视图中： CLUSTERING_FACTOR 表示的。看一下官方介绍：

Indicates the amount of order of the rows in the table based on the values of the index.

往往聚簇因子的大小和数据获取的I/o存在一定的相似性。如果聚簇因子大，那么相对的物理或是逻辑（一般是）i/o开销很大，也就是块被频繁反复读取，一致数据获取很慢。

长查询的视图有dba_ind_statistics和dba_tab_statistics

第三种：使用不等条件：

当使用在进行查询数据的时候使用不等条件，，那么oracle任务这个符号会需要读取大部分的数据块，那么就会跳过使用索引。eg：

SQL> select index_name,table_name,column_name from user_ind_columns where table_name='EMP';

INDEX_NAME TABLE_NAME COLUMN_NAME
------------------------------ ------------------------------ ----------------------------------------
EMP_IDX1 EMP DEPTNO
EMP_IDX1 EMP EMPNO

SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
7782 CLARK MANAGER 7839 09-JUN-81 2450 10
7839 KING PRESIDENT 17-NOV-81 5000 10
7934 MILLER CLERK 7782 23-JAN-82 1300 10
7369 SMITH CLERK 7902 17-DEC-80 800 20
7566 JONES MANAGER 7839 02-APR-81 2975 20
7788 SCOTT ANALYST 7566 19-APR-87 3000 20
7876 ADAMS CLERK 7788 23-MAY-87 1100 20
7902 FORD ANALYST 7566 03-DEC-81 3000 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30
7900 JAMES CLERK 7698 03-DEC-81 950 30

14 rows selected.

SQL> set autotrace trace exp
SQL> select * from emp where empno7900;

Execution Plan
----------------------------------------------------------
Plan hash value: 822536733