众所周知，索引确实可以提高数据库的性能。但是大家对索引的使用限制却一口未提。笔者认为对于数据库索引的作用，应该分两面看。除了肯定其对数据库性能带来的正面影响外，还需要认识到其可能带来的负面影响。只有如此，数据库管理员才能够在正确的场合使用正确的索引。要知道有时候一个错误的索引可能引发死锁，并导致数据库性能的急剧下降或进程终止；而如果数据库管理员能够做出一个正确的判断的话，那么可以使那些本来要运行几个小时甚至一天的进程在几分钟之内就能够完成。所以这两个差距是一个天上、一个地下。故笔者希望通过这篇文章能够让各位读者了解索引在使用过程中的限制，了解索引并不是万能的。
一、索引对数据库性能的影响跟数据选择性直接挂钩。

当用户从数据表中查询数据时，Oracle数据库提供了两种查询的方式。一是从表中读取每一行，就是大家常说的全表扫描；二是通过ROWID一此读取一行。当表中记录比较多的时候，很明显第二种方式能够更快的定位记录内容。而索引其实就是建立在这个查询原理之上的。如现在某个表中有300多万条记录，而现在用户可能只需要了解其中的10条记录信息。此时如果使用索引标识读取的块，则可以执行比较少的I/O，数据库系统会很快找到用户所需要的内容。而如果没有使用索引的话，则需要读取表中所有的块。

如果在这个表中加入了索引，那么到底对数据库的性能影响有多大呢？这个就不好说了，因为其跟很多因素相关。如跟数据选择性直接相关。如果用户的数据非常具有选择性，则表中家功能只有很少的行匹配索引值，则Oracle将能够快速查询匹配所引值得ROWID的索引，并且可以快速查询少量的相关表快。如还是上面这个表中，其如果存储有某个市的所有常住人口信息，其中身份证号码肯定是少不了的。如此时用户想根据身份证号码来查询某个人的信息时，那么数据库能够在很短的时间内给出响应。这主要是因为用户提供的数据非常具有选择性，基本上跟数据库中的索引值是一一对应的。而如果用户想通过出身年月信息来查询信息的话，则其数据库反映的速度就会比较慢了。

可见索引对数据库性能的影响直接跟数据的选择性挂钩。这对于数据库管理员设计索引时很有启发性。如数据库管理员在设计索引时，最好能够选择哪些具有唯一性的字段或者重复性比较少的字段。如此的话，索引对于数据库性能来说才有比较大的价值。

二、索引效果跟数据库中记录的具体存储位置相关。

还是上面这张表中，如果现在用户想查找年龄超过100岁的老人，要对他们去进行慰问。假设现在符合这个条件的人只有10人。那么此时索引对数据库性能会有怎么样的影响呢？此时显然数据非常具有选择性，但是并不一定索引能够起到很好的效果。这还要看其具体存储的位置。如果这十条记录在硬盘中存储的物理位置比较近，如可能在同一个扇区之内，则此时索引对于数据库性能的影响就会比较大，能够在最短时间内找到符合条件的数据。但是如果相关的行在表中存储的位置并不互相靠近，则这个索引的效果就会逐渐减少。因为如果匹配索引值的数据分散在硬盘上的多个酷爱时，则必须从表中选择多个单独的块以满足查询。

数据库管理员对于这一点要特别注意。因为此时如果数据库管理员查用了索引的话，那么很可能是画蛇添足。笔者建议，当数据库管理员发现数据分散在表的多个块的时候，最好是不要使用索引，而是执行全表扫描。此时执行扫描反而会比执行索引的效率更高。因为在执行全表扫描的时候，Oracle数据库系统会使用多块读取以加速扫描表。而如果采用索引的话，则其读取数据时是单块读取的。而由于数据存储在多个块中，所以其读取的速度反而会更慢。

由此可见，Oracle数据库管理员在数据库设计与日常维护中，也要想办法能够让数据尽量存储在临近的位置。如尽量减少在同一个服务器中不要部署不同的应用服务，防止硬盘产生过多的磁盘碎片；如需要采用多块硬盘的话，则最好通过表空间把类似的表放在同一个表空间中，从而让相关的行在表zhognd存储位置尽量靠近，以提高索引的使用效果。也就是说，数据库管理员在使用索引的时候，为表中的字段建立了索引这只是其工作的第一步。在后续数据库维护与调整的过程中，仍然要注意数据存储位置对索引的影响。

通常情况下，索引可以提高数据库的性能。如通过索引，则Select、Update、、Delete语句的Where子句的性能可以从索引中获得收益。但是这并不是百分之百准确的。或者说，只有这些语句涉及到的行比较少的时候，这个原则是准确的。但是如果所涉及到的行比较多，则这个索引的应用反而会降低数据库的性能。

如现在数据库系统中有一张表，其中包含了300万条记录。而用户现在需要利用Delete语句删除其中100万条记录。如想要把记录创建日期为2005年12月31日前的数据全部删除掉。此时虽然采用了Where子句的限制条件，但是这个时候因为删除的数据量太多，其并不能够从索引中获取什么好处。因为利用delete语句删除记录的时候，同时需要删除相关的索引。当Delete语句需要删除将近表中一半的记录的时候，同时需要删除跟这个表相关的近一半的索引，这个过程是非常耗时的。为此大量行的Delete操作会因为表中存在索引而降低其执行速度。另外Insert语句也会有类似的现象。通常情况下，增加索引会降低Insert语句的执行新能。因为在执行insert语句的时候，由于索引的存在，数据库需要同时往数据表与索引表中插入数据。为此，从理论上来说，数据库表中的每个索引都回使得对这个表进行Insert操作时速度减慢两倍；而在这个数据表上使用两条索引则会使得插入速度减慢一倍。

可见并不是所有语句或者操作都能够从索引中获得收益。为此数据库管理员必须要了解索引跟一些常用命令之间的冲突。只有如此数据库管理员才能够在索引给某些操作带来的收益与损失之间取得一个均衡，并根据相关的操作来调整索引。对于这一点笔者有如下几个建议，大家可以参考一下。

一是当需要网一个表中插入大量数据的时候，最好能够先把索引取消，以提高插入的速度。如现在数据库管理员需要往表Product中添加记录的话，无论其采用什么方式，如采用Select into语句，还是采用图形化的导入工具都好。当需要插入的记录比较多的时候，最好先把索引禁用掉。此时数据库只需要在数据表中插入数据即可，而不用维护索引表。等到数据导入完成之后，再起用这个索引。此时数据库会重建这些记录的索引。这是大部分数据库管理员在数据插入的过程中常用的手段。可以明显提高数据库的插入性能。

二是当因为某些原因需要清空数据库表中的记录时，如果这张数据表中的记录比较多时，则可以考虑一下先把表中的索引取消掉，然后再执行删除操作。如此的话数据库系统在删除数据的时候，就不用同时维护数据表与索引表了。故可以成倍提高Delete的操作效率。等到删除操作执行完毕后，再启用索引。

当受影响的记录比较多时，上面这两个建议可以明显的提高数据库的执行性能。特别是在应用系统初始化的过程中，可能需要导入大量的初始化记录。有时候可能发现数据导入有错误需要整张表清空等等。此时如果先把索引禁用掉的话，则数据库管理员会发现，期初数据导入会变得顺利许多。

数据库系统强制性的要求。即使不采用这些建议，数据库最终也可以完成相关的任务。只是其速度上可能会有差异。而且随着记录的不同，这个差异有时候可能会相差几十个小时。总之笔者认为作为一个优秀的数据库管理员，应该了解索引在不同情况下对数据库系统的影响。大丈夫能屈能伸。在必要的情况下，数据库管理员要敢于取消索引，以提高某些操作的性能。


索引( Index )是常见的数据库对象，它的设置好坏、使用是否得当，极大地影响数据库应用程序和Database 的性能。虽然有许多资料讲索引的用法， DBA 和 Developer 们也经常与它打交道，但笔者发现，还是有不少的人对它存在误解，因此针对使用中的常见问题，讲三个问题。此文所有示例所用的数据库是 Oracle 8.1.7 OPS on HP N series ,示例全部是真实数据，读者不需要注意具体的数据大小，而应注意在使用不同的方法后，数据的比较。本文所讲基本都是陈词滥调，但是笔者试图通过实际的例子，来真正让您明白事情的关键。

第一讲、索引并非总是最佳选择

如果发现Oracle 在有索引的情况下，没有使用索引，这并不是Oracle 的优化器出错。在有些情况下，Oracle 确实会选择全表扫描（Full Table Scan）,而非索引扫描（Index Scan）。这些情况通常有：

1. 表未做statistics, 或者 statistics 陈旧，导致 Oracle 判断失误。

2. 根据该表拥有的记录数和数据块数，实际上全表扫描要比索引扫描更快。

对第1种情况，最常见的例子，是以下这句sql 语句：

select count(*) from mytable;

在未作statistics 之前，它使用全表扫描，需要读取6000多个数据块（一个数据块是8k）, 做了statistics 之后，使用的是 INDEX (FAST FULL SCAN) ，只需要读取450个数据块。但是，statistics 做得不好，也会导致Oracle 不使用索引。

第2种情况就要复杂得多。一般概念上都认为索引比表快，比较难以理解什么情况下全表扫描要比索引扫描快。为了讲清楚这个问题，这里先介绍一下Oracle 在评估使用索引的代价（cost）时两个重要的数据：CF(Clustering factor) 和 FF(Filtering factor).

CF: 所谓 CF, 通俗地讲，就是每读入一个索引块，要对应读入多少个数据块。

FF: 所谓 FF, 就是该sql 语句所选择的结果集，占总的数据量的百分比。

大约的计算公式是：FF * (CF + 索引块个数) ，由此估计出，一个查询， 如果使用某个索引，会需要读入的数据块块数。需要读入的数据块越多，则 cost 越大，Oracle 也就越可能不选择使用 index. （全表扫描需要读入的数据块数等于该表的实际数据块数）

其核心就是， CF 可能会比实际的数据块数量大。CF 受到索引中数据的排列方式影响，通常在索引刚建立时，索引中的记录与表中的记录有良好的对应关系，CF 都很小；在表经过大量的插入、修改后，这种对应关系越来越乱，CF 也越来越大。此时需要 DBA 重新建立或者组织该索引。

如果某个sql 语句以前一直使用某索引，较长时间后不再使用，一种可能就是 CF 已经变得太大，需要重新整理该索引了。

FF 则是Oracle 根据 statistics 所做的估计。比如, mytables 表有32万行，其主键myid的最小值是1，最大值是409654，考虑以下sql 语句：

Select * from mytables where myid>=1; 和

Select * from mytables where myid>=400000

这两句看似差不多的 sql 语句，对Oracle 而言，却有巨大的差别。因为前者的 FF 是100%， 而后者的 FF 可能只有 1%。如果它的CF 大于实际的数据块数，则Oracle 可能会选择完全不同的优化方式。而实际上，在我们的数据库上的测试验证了我们的预测. 以下是在HP 上执行时它们的 explain plan:

第一句：

SQL> select * from mytables where myid>=1;

已选择325917行。

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3132 Card=318474 Byt es=141402456)

1 0 TABLE ACCESS (FULL) OF 'MYTABLES' (Cost=3132 Card=318474 Byt es=141402456)

Statistics

----------------------------------------------------------

7 recursive calls

89 db block gets

41473 consistent gets

19828 physical reads


0 redo size

131489563 bytes sent via SQL*Net to client

1760245 bytes received via SQL*Net from client

21729 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

325917 rows processed

第二句：

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=346 Card=663 Bytes=2 94372)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'MYTABLES' (Cost=346 Card=663

Bytes=294372)

2 1 INDEX (RANGE SCAN) OF 'PK_MYTABLES' (UNIQUE) (Cost=5 Card=663)

Statistics

----------------------------------------------------------

1278 recursive calls

0 db block gets

6647 consistent gets

292 physical reads

0 redo size

3544898 bytes sent via SQL*Net to client

42640 bytes received via SQL*Net from client

524 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

7838 rows processed

显而易见，第1句没有使用索引，第2句使用了主键索引pk_mytables. FF的巨大影响由此可见一斑。由此想到，我们在写sql 语句时，如果预先估计一下 FF, 你就几乎可以预见到 Oracle 会否使用索引。

第二讲、索引也有好坏

索引有 B tree 索引， Bitmap 索引， Reverse b tree 索引， 等。最常用的是 B tree 索引。 B 的全称是Balanced , 其意义是，从 tree 的 root 到任何一个leaf ，要经过同样多的 level. 索引可以只有一个字段（Single column）, 也可以有多个字段（Composite）,最多32个字段，8I 还支持 Function-based index. 许多developer 都倾向于使用单列B 树索引。

所谓索引的好坏是指：

1，索引不是越多越好。特别是大量从来或者几乎不用的索引，对系统只有损害。OLTP系统每表超过5个索引即会降低性能，而且在一个sql 中， Oracle 从不能使用超过 5个索引。

2，很多时候，单列索引不如复合索引有效率。

3，用于多表连结的字段，加上索引会很有作用。

那么，在什么情况下单列索引不如复合索引有效率呢？有一种情况是显而易见的，那就是，当sql 语句所查询的列，全部都出现在复合索引中时，此时由于 Oracle 只需要查询索引块即可获得所有数据，当然比使用多个单列索引要快得多。（此时，这种优化方式被称为 Index only access path）

除此之外呢？我们还是来看一个例子吧：

在 HP（Oracle 8.1.7） 上执行以下语句：

select count(1) from mytabs where coid>=130000 and issuedate >= to_date ('2001-07-20','yyyy-mm-dd')。

一开始，我们有两个单列索引：I_mytabs1(coid), I_mytabs2(issuedate), 下面是执行情况：

COUNT(1)

----------

6427

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=384 Card=1 Bytes=11)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (BY INDEX ROWID) OF 'T_MYTABS' (Cost=384 Card

=126 Bytes=1386)

3 2 INDEX (RANGE SCAN) OF 'I_MYTABS2' (NON-UNIQUE) (Cost=11

Card=126)

Statistics

----------------------------------------------------------

172 recursive calls

1 db block gets

5054 consistent gets

2206 physical reads

0 redo size

293 bytes sent via SQL*Net to client

359 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

5 sorts (memory)

0 sorts (disk)

1 rows processed

可以看到，它读取了7000个数据块来获得所查询的 6000多行。

现在，去掉这两个单列索引，增加一个复合索引I_mytabs_test ( coid, issuedate), 重新执行，结果如下：


COUNT(1)

----------

6436

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=11)

1 0 SORT (AGGREGATE)

2 1 INDEX (RANGE SCAN) OF 'I_MYTABS_TEST' (NON-UNIQUE) (Cost=3 Card=126 Bytes=1386)

Statistics

----------------------------------------------------------

806 recursive calls

5 db block gets

283 consistent gets

76 physical reads

0 redo size

293 bytes sent via SQL*Net to client

359 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

3 sorts (memory)

0 sorts (disk)

1 rows processed

可以看到，这次只读取了300个数据块。

7000块对300块，这就是在这个例子中，单列索引与复合索引的代价之比。这个例子提示我们， 在许多情况下，单列索引不如复合索引有效率。

可以说，在索引的设置问题上，其实有许多工作可以做。正确地设置索引，需要对应用进行总体的分析。

第三讲、索引再好，不用也是白搭

抛开前面所说的，假设你设置了一个非常好的索引，任何傻瓜都知道应该使用它，但是Oracle 却偏偏不用，那么，需要做的第一件事情，是审视你的 sql 语句。

Oracle 要使用一个索引，有一些最基本的条件：
　　1， where 子句中的这个字段，必须是复合索引的第一个字段；
　　2， where 子句中的这个字段，不应该参与任何形式的计算

具体来讲，假设一个索引是按 f1, f2, f3的次序建立的，现在有一个 sql 语句, where 子句是 f2 = : var2, 则因为 f2 不是索引的第1个字段，无法使用该索引。

第2个问题，则在我们之中非常严重。以下是从 实际系统上面抓到的几个例子：

Select jobid from mytabs where isReq='0' and to_date (updatedate) >= to_Date ( '2001-7-18', 'YYYY-MM-DD')；

………

以上的例子能很容易地进行改进。请注意这样的语句每天都在我们的系统中运行，消耗我们有限的cpu 和 内存资源。

除了1，2这两个我们必须牢记于心的原则外，还应尽量熟悉各种操作符对 Oracle 是否使用索引的影响。这里我只讲哪些操作或者操作符会显式（explicitly）地阻止 Oracle 使用索引。以下是一些基本规则：

1， 如果 f1 和 f2 是同一个表的两个字段，则 f1>f2, f1>=f2, f1
　　2， f1 is null, f1 is not null, f1 not in, f1 !=, f1 like ‘%pattern%’;
　　3， Not exist
　　4， 某些情况下，f1 in 也会不用索引

对于这些操作，别无办法，只有尽量避免。比如，如果发现你的 sql 中的 in 操作没有使用索引，也许可以将 in 操作改成 比较操作 + union all。笔者在实践中发现很多时候这很有效。

但是，Oracle 是否真正使用索引，使用索引是否真正有效，还是必须进行实地的测验。合理的做法是，对所写的复杂的 sql, 在将它写入应用程序之前，先在产品数据库上做一次explain . explain 会获得Oracle 对该 sql 的解析（plan）,可以明确地看到 Oracle 是如何优化该 sql 的。

如果经常做 explain, 就会发现，喜爱写复杂的 sql 并不是个好习惯，因为过分复杂的sql 其解析计划往往不尽如人意。事实上，将复杂的 sql 拆开，有时候会极大地提高效率，因为能获得很好的优化。当然这已经是题外话了。

本文只讨论Oracle中最常见的索引，即是B-tree索引。本文中涉及的数据库版本是Oracle8i。

一. 查看系统表中的用户索引
在Oracle中，SYSTEM表是安装数据库时自动建立的，它包含数据库的全部数据字典，存储过程、包、函数和触发器的定义以及系统回滚段。
一般来说，应该尽量避免在SYSTEM表中存储非SYSTEM用户的对象。因为这样会带来数据库维护和管理的很多问题。一旦SYSTEM表损坏了，只能重新生成数据库。我们可以用下面的语句来检查在SYSTEM表内有没有其他用户的索引存在。
select count(*)
from dba_indexes
where tablespace_name = 'SYSTEM'
and owner not in ('SYS','SYSTEM')
/
二. 索引的存储情况检查
Oracle为数据库中的所有数据分配逻辑结构空间。数据库空间的单位是数据块（block）、范围（extent）和段（segment）。
Oracle数据块（block）是Oracle使用和分配的最小存储单位。它是由数据库建立时设置的DB_BLOCK_SIZE决定的。一旦数据库生成了，数据块的大小不能改变。要想改变只能重新建立数据库。（在Oracle9i中有一些不同，不过这不在本文讨论的范围内。）
Extent是由一组连续的block组成的。一个或多个extent组成一个segment。当一个segment中的所有空间被用完时，Oracle为它分配一个新的extent。
　
Segment是由一个或多个extent组成的。它包含某表空间中特定逻辑存储结构的所有数据。一个段中的extent可以是不连续的，甚至可以在不同的数据文件中。
一个object只能对应于一个逻辑存储的segment，我们通过查看该segment中的extent，可以看出相应object的存储情况。
（1）查看索引段中extent的数量：
select segment_name, count(*)
from dba_extents
where segment_type='INDEX'
and owner=UPPER('&owner')
group by segment_name
/
（2）查看表空间内的索引的扩展情况：
select
substr(segment_name,1,20) "SEGMENT NAME",
bytes,
count(bytes)
from dba_extents
where segment_name in
( select index_name
from dba_indexes
where tablespace_name=UPPER('&表空间'))
group by segment_name,bytes
order by segment_name
/
三. 索引的选择性
索引的选择性是指索引列中不同值的数目与表中记录数的比。如果一个表中有2000条记录，表索引列有1980个不同的值，那么这个索引的选择性就是1980/2000=0.99。
一个索引的选择性越接近于1，这个索引的效率就越高。
如果是使用基于cost的最优化，优化器不应该使用选择性不好的索引。如果是使用基于rule的最优化，优化器在确定执行路径时不会考虑索引的选择性（除非是唯一性索引），并且不得不手工优化查询以避免使用非选择性的索引。
确定索引的选择性，可以有两种方法：手工测量和自动测量。
（1）手工测量索引的选择性
如果要根据一个表的两列创建两列并置索引，可以用以下方法测量索引的选择性：
列的选择性=不同值的数目/行的总数 /* 越接近1越好 */
select count(distinct 第一列||'%'||第二列)/count(*)
from 表名
/
如果我们知道其中一列索引的选择性（例如其中一列是主键），那么我们就可以知道另一列索引的选择性。
手工方法的优点是在创建索引前就能评估索引的选择性。
（2）自动测量索引的选择性
如果分析一个表，也会自动分析所有表的索引。
第一，为了确定一个表的确定性，就要分析表。
analyze table 表名
compute statistics
/
第二，确定索引里不同关键字的数目：
select distinct_keys
from user_indexes
where table_name='表名'
and index_name='索引名'
/
第三，确定表中行的总数：
select num_rows
from user_tables
where table_name='表名'
/
第四，索引的选择性=索引里不同关键字的数目/表中行的总数：
select i.distinct_keys/t.num_rows
from
user_indexes i,
user_tables t
where i.table_name='表名'
and i.index_name='索引名'
and i.table_name=t.table_name
/
第五，可以查询USER_TAB_COLUMNS以了解每个列的选择性。
表中所有行在该列的不同值的数目：
select
column_name,
num_distinct
from user_tab_columns
where table_name='表名'
/
列的选择性=NUM_DISTINCT/表中所有行的总数，查询USER_TAB_COLUMNS有助测量每个列的选择性，但它并不能精确地测量列的并置组合的选择性。要想测量一组列的选择性，需要采用手工方法或者根据这组列创建一个索引并重新分析表。

四. 确定索引的实际碎片
随着数据库的使用，不可避免地对基本表进行插入，更新和删除，这样导致叶子行在索引中被删除，使该索引产生碎片。插入删除越频繁的表，索引碎片的程度也越高。碎片的产生使访问和使用该索引的I/O成本增加。碎片较高的索引必须重建以保持最佳性能。
（1）利用验证索引命令对索引进行验证。
这将有价值的索引信息填入index_stats表。
validate index 用户名.索引名
/
（2）查询index_stats表以确定索引中删除的、未填满的叶子行的百分比。
select
name,
del_lf_rows,
lf_rows,
round((del_lf_rows/(lf_rows+0.0000000001))*100) "Frag Percent"
from index_stats
/
（3）如果索引的叶子行的碎片超过10%，考虑对索引进行重建。
alter index 用户名.索引名 rebuild
tablespace 表空间名
storage(initial 初始值 next 扩展值)
nologging
/
（4）如果出于空间或其他考虑，不能重建索引，可以整理索引。
alter index用户名.索引名 coalesce
/
（5）清除分析信息
analyze index 用户名.索引名
delete statistics
/

五. 重建索引
（1）检查需要重建的索引。
根据以下几方面进行检查，确定需要重建的索引。
第一，查看SYSTEM表空间中的用户索引。
为了避免数据字典的碎片出现，要尽量避免在SYSTEM表空间出现用户的表和索引。
select index_name
from dba_indexes
where tablespace_name='SYSTEM'
and owner not in ('SYS','SYSTEM')
/
第二，确保用户的表和索引不在同一表空间内。
表和索引对象的第一个规则是把表和索引分离。把表和相应的索引建立在不同的表空间中，最好在不同的磁盘上。这样可以避免在数据管理和查询时出现的许多I/O冲突。
set linesize 120
col "OWNER" format a20
col "INDEX" format a30
col "TABLE" format a30
col "TABLESPACE" format a30
select
i.owner "OWNER",
i.index_name "INDEX",
t.table_name "TABLE",
i.tablespace_name "TABLESPACE"
from
dba_indexes i,
dba_tables t
where i.owner=t.owner
and i.table_name=t.table_name
and i.tablespace_name=t.tablespace_name
and i.owner not in ('SYS','SYSTEM')
/
第三，查看数据表空间里有哪些索引
用户的默认表空间应该不是SYSTEM表空间，而是数据表空间。在建立索引时，如果不指定相应的索引表空间名，那么，该索引就会建立在数据表空间中。这是程序员经常忽略的一个问题。应该在建索引时，明确的指明相应的索引表空间。
col segment_name format a30
select
owner,
segment_name,
sum(bytes)
from dba_segments
where tablespace_name='数据表空间名'
and segment_type='INDEX'
group by owner,segment_name
/


第四，查看哪个索引被扩展了超过10次
随着表记录的增加，相应的索引也要增加。如果一个索引的next extent值设置不合理（太小），索引段的扩展变得很频繁。索引的extent太多，检索时的速度和效率就会降低。
set linesize 100
col owner format a10
col segment_name format a30
col tablespace_name format a30
select
count(*),
owner,
segment_name,
tablespace_name
from dba_extents
where segment_type='INDEX'
and owner not in ('SYS','SYSTEM')
group by owner,segment_name,tablespace_name
having count(*) >10
order by count(*) desc
/
（2）找出需要重建的索引后，需要确定索引的大小，以设置合理的索引存储参数。
set linesize 120
col "INDEX" format a30
col "TABLESPACE" format a20
select
owner "OWNER",
segment_name "INDEX",
tablespace_name "TABLESPACE",
bytes "BYTES/COUNT",
sum(bytes) "TOTAL BYTES",
round(sum(bytes)/(1024*1024),0) "TOTAL M",
count(bytes) "TOTAL COUNT"
from dba_extents
where segment_type='INDEX'
and segment_name in
(
'索引名1',
'索引名2',
......
)
group by owner,segment_name,segment_type,tablespace_name,bytes
order by owner,segment_name
/
（3）确定索引表空间还有足够的剩余空间。
确定要把索引重建到哪个索引表空间中。要保证相应的索引表空间有足够的剩余空间。
select round(bytes/(1024*1024),2) free(M)
from sm$ts_free
where tablespace_name='表空间名'
/
（4）重建索引。
重建索引时要注意以下几点：
a.如果不指定tablespace名，索引将建在用户的默认表空间。
b.如果不指定nologging，将会写日志，导致速度变慢。由于索引的重建没有恢复的必要，所以，可以不写日志。
c.如果出现资源忙，表明有进程正在使用该索引，等待一会再提交。
alter index 索引名
rebuild
tablespace 索引表空间名
storage(initial 初始值 next 扩展值)
nologging
/
（5）检查索引。
对重建好的索引进行检查。
select *
from dba_extents
where segment_name='索引名'
/
（6）根据索引进行查询，检查索引是否有效
使用相应的where条件进行查询，确保使用该索引。看看使用索引后的效果如何。
select *
from dba_ind_columns
where index_name like '表名%'
/
然后，根据相应的索引项进行查询。
select *
from '表名%'
where ......
/
（7）找出有碎片的表空间，并收集其碎片。
重建索引后，原有的索引被删除，这样会造成表空间的碎片。
select 'alter tablespace '||tablespace_name||' coalesce;'
from dba_free_space_coalesced
where percent_blocks_coalesced!=100
/
整理表空间的碎片。
alter tablespace 表空间名 coalesce
/