索引( Index )是常见的数据库对象，它的设置好坏、使用是否得当，极大地影响数据库应用程序和 的性能。虽然DBA 和 要经常与它打交道，但尚观发现还是有不少的人对它存在误解，我们今天希望你可以真正明白它的关键。
一、索引并非总是最佳选择
如果发现 在有索引的情况下，没有使用索引，这并不是 的优化器出错。在有些情况下， 确实会选择全表扫描（Full Table Scan）,而非索引扫描（Index Scan）。这些情况通常有：
1. 表未做, 或者 陈旧，导致 判断失误。
2. 根据该表拥有的记录数和数据块数，实际上全表扫描要比索引扫描更快。
对第1种情况，最常见的例子，是以下这句sql语句：
count(*) from ;
在未作 之前，它使用全表扫描，需要读取6000多个数据块（一个数据块是8k）, 做了 之后，使用的是 INDEX (FAST FULL SCAN) ，只需要读取450个数据块。但是， 做得不好，也会导致 不使用索引。
第2种情况就要复杂得多。一般概念上都认为索引比表快，比较难以理解什么情况下全表扫描要比索引扫描快。为了讲清楚这个问题，这里先介绍一下 在评估使用索引的代价（cost）时两个重要的数据：CF( ) 和 FF( ).
CF: 所谓 CF, 通俗地讲，就是每读入一个索引块，要对应读入多少个数据块。
FF: 所谓 FF, 就是该sql语句所选择的结果集，占总的数据量的百分比。
大约的计算公式是：FF * (CF + 索引块个数) ，由此估计出，一个查询，如果使用某个索引，会需要读入的数据块块数。需要读入的数据块越多，则 cost 越大， 也就越可能不选择使用 index. （全表扫描需要读入的数据块数等于该表的实际数据块数）其核心就是， CF 可能会比实际的数据块数量大。CF 受到索引中数据的排列方式影响，通常在索引刚建立时，索引中的记录与表中的记录有良好的对应关系，CF 都很小；在表经过大量的插入、修改后，这种对应关系越来越乱，CF 也越来越大。此时需要 DBA 重新建立或者组织该索引。
如果某个sql语句以前一直使用某索引，较长时间后不再使用，一种可能就是 CF 已经变得太大，需要重新整理该索引了。
FF 则是 根据 所做的估计。比如, 表有32万行，其主键myid的最小值是1，最大值是，考虑以下sql语句：
* from where myid>=1; 和
* from where myid>=
这两句看似差不多的sql语句，对 而言，却有巨大的差别。因为前者的 FF 是100%，而后者的 FF 可能只有 1%。如果它的CF 大于实际的数据块数，则 可能会选择完全不同的优化方式。而实际上，在我们的数据库上的测试验证了我们的预测. 以下是在HP 上执行时它们的 plan:
第一句：
SQL> * from where myid>=1;
已选择行。
Plan
0 = (Cost=3132 Card= Bytes=)
1 0 TABLE (FULL) OF '' (Cost=3132 Card= Bytes=)
7 calls
89 db block gets
41473 gets
19828 reads
0 redo size
bytes sent via SQL*Net to
bytes via SQL*Net from
21729 SQL*Net to/from
1 sorts ()
0 sorts (disk)
rows
第二句：
Plan
0 = (Cost=346 Card=663 Bytes=2 94372)
1 0 TABLE (BY INDEX ROWID) OF '' (Cost=346 Card=663
Bytes=)
2 1 INDEX (RANGE SCAN) OF '' () (Cost=5 Card=663)
1278 calls
0 db block gets
6647 gets
292 reads
0 redo size
bytes sent via SQL*Net to
42640 bytes via SQL*Net from
524 SQL*Net to/from
1 sorts ()
0 sorts (disk)
7838 rows
显而易见，第1句没有使用索引，第2句使用了主键索引. FF的巨大影响由此可见一斑。由此想到，我们在写sql语句时，如果预先估计一下 FF, 你就几乎可以预见到 会否使用索引。
二、索引也有好坏
索引有 B tree 索引， 索引， b tree 索引，等。最常用的是 B tree 索引。 B 的全称是 , 其意义是，从 tree 的 root 到任何一个leaf ，要经过同样多的 level. 索引可以只有一个字段（ ）, 也可以有多个字段（）,最多32个字段，8I 还支持 -based index. 许多 都倾向于使用单列B 树索引。
所谓索引的好坏是指：
1，索引不是越多越好。特别是大量从来或者几乎不用的索引，对系统只有损害。OLTP系统每表超过5个索引即会降低性能，而且在一个sql中oracle索引， 从不能使用超过 5个索引。
2，很多时候oracle索引，单列索引不如复合索引有效率。
3，用于多表连结的字段，加上索引会很有作用。
那么，在什么情况下单列索引不如复合索引有效率呢？有一种情况是显而易见的，那就是，当sql语句所查询的列，全部都出现在复合索引中时，此时由于 只需要查询索引块即可获得所有数据，当然比使用多个单列索引要快得多。（此时，这种优化方式被称为 Index only path）
除此之外呢？我们还是来看一个例子吧：
在 HP（ 8.1.7）上执行以下语句：
count(1) from where coid>= and >= ('2001-07-20', 'yyyy-mm-dd')。
一开始，我们有两个单列索引：(coid), (), 下面是执行情况：
COUNT(1)
6427
Plan
0 = (Cost=384 Card=1 Bytes=11)
1 0 SORT ()
2 1 TABLE (BY INDEX ROWID) OF '' (Cost=384 Card
=126 Bytes=1386)
3 2 INDEX (RANGE SCAN) OF '' (NON-) (Cost=11
Card=126)
172 calls
1 db block gets
5054 gets
2206 reads
0 redo size
293 bytes sent via SQL*Net to
359 bytes via SQL*Net from
2 SQL*Net to/from
5 sorts ()
0 sorts (disk)
1 rows
可以看到，它读取了7000个数据块来获得所查询的 6000多行。
现在，去掉这两个单列索引，增加一个复合索引 ( coid, ), 重新执行，结果如下：
COUNT(1)
6436
Plan
0 = (Cost=3 Card=1 Bytes=11)
1 0 SORT ()
2 1 INDEX (RANGE SCAN) OF '' (NON-) (Cost=3 Card=126 Bytes=1386)
806 calls
5 db block gets
283 gets
76 reads
0 redo size
293 bytes sent via SQL*Net to
359 bytes via SQL*Net from
2 SQL*Net to/from
3 sorts ()
0 sorts (disk)
1 rows
可以看到，这次只读取了300个数据块。
7000块对300块，这就是在这个例子中，单列索引与复合索引的代价之比。这个例子提示我们，在许多情况下，单列索引不如复合索引有效率。
可以说，在索引的设置问题上，其实有许多工作可以做。正确地设置索引，需要对应用进行总体的分析。
是否真正使用索引，使用索引是否真正有效，还是必须进行实地的测验。
更多技术好礼，点击文末链接咨询尚观科技：
官方合作伙伴WDP计划最佳认证中心
限时特惠:本站持续每日更新海量各大内部创业课程，一年会员仅需要98元，全站资源免费下载
点击查看详情
站长微信:Jiucxh
