13518219792
------索引名不能重复，如果要重新建同名索引，必须把以前的索引删掉在建索引
创新互联公司-专业网站定制、快速模板网站建设、高性价比墨竹工卡网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式墨竹工卡网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖墨竹工卡地区。费用合理售后完善，十年实体公司更值得信赖。
-----删除索引
drop index 索引名;
-----创建索引
create index 索引名 on 表名 (表中的字段,表中的字段)
tablespace 指定的表空间
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
1、重新收集统计信息
analyze table 表名 compute statistics for table for all indexes for all indexed columns
analyze index 索引名 compute statistics
2、把表现不同的sql及其执行计划发上来看看
重建索引有多种方式，如drop and re-create、rebuild、rebuild online等。下面简单比较这几种方式异同以及优缺点：
首先建立测试表及数据：
SQL CREATE TABLE TEST AS SELECT CITYCODE C1 FROM CITIZENINFO2;
Table created
SQL ALTER TABLE TEST MODIFY C1 NOT NULL;
Table altered
SQL SELECT COUNT(1) FROM TEST;
COUNT(1)
----------
16000000
一、drop and re-create和rebuild
首先看看正常建立索引时，对表的加锁情况。
suk@ORACLE9I @show_sid
SID
----------
14
suk@ORACLE9I CREATE INDEX IDX_TEST_C1 ON TEST(C1);
索引已创建。
SQL SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
OBJ$ 3
TEST 4
可见，普通情况下建立索引时，oracle会对基表加share锁，由于share锁和 row-X是不兼容的，也就是说，在建立索引期间，无法对基表进行DML操作。
对于删除重建索引的方法就不介绍了，它与上面的描述是一样的，下面我们看看用rebuild的方式建立索引有什么特别。
suk@ORACLE9I ALTER INDEX IDX_TEST_C1 REBUILD;
索引已更改。
另开一个会话，查询此时test的加锁情况：
SQL SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
TEST 4
可见，rebuild的方式对基表的加锁方式与CREATE时是一样的。
另开一个会话，在索引正在rebuild时，执行如下SQL：
suk@ORACLE9I SET AUTOTRACE TRACE
suk@ORACLE9I SELECT /*+ INDEX(TEST) */ COUNT(1) FROM TEST WHERE ROWNUM10;
执行计划
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=26 Card=1)
1 0 SORT (AGGREGATE)
2 1 COUNT (STOPKEY)
3 2 INDEX (FULL SCAN) OF 'IDX_TEST_C1' (NON-UNIQUE) (Cost=
26 Card=1986621)
可以看到索引在重建时，查询仍然可以使用旧索引。实际上，oracle在rebuild时，在创建新索引过程中，并不会删除旧索引，直到新索引rebuild成功。
从这点可以知道rebuild比删除重建的一个好处是不会影响原有的SQL查询，但也正由于此，用rebuild方式建立索引需要相应表空间的空闲空间是删除重建方式的2倍。
重建索引有多种方式，如drop and re-create、rebuild、rebuild online等。下面简单比较这几种方式异同以及优缺点：
相关文章：
oracle重建索引（一）
二、rebuild 和rebuild online
首先我们跟踪一下rebuild online的过程。
另开一个会话查看锁的信息：
SQL SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
SYS_JOURNAL_10499 4
TEST 2
SQL INSERT INTO TEST VALUES(11);
1 row inserted
SQL COMMIT;
Commit complete
可以看到，在rebuild online期间，oracle对基表加的是RS所，此时我们可以对基表进行DML操作。但奇怪的话在相同的session中有一个SYS_JOURNAL_10499表被加SHARE锁，这个表是干什么用的呢？
我们看看trace文件，有这样的信息：
create table "SUK"."SYS_JOURNAL_10499" (C0 NUMBER(6,0), opcode char(1),
partno number, rid rowid, primary key( C0 , rid )) organization index
TABLESPACE "TEST"
CREATE UNIQUE INDEX "SUK"."SYS_IOT_TOP_10605" on
"SUK"."SYS_JOURNAL_10499"("C0","RID") INDEX ONLY TOPLEVEL TABLESPACE "TEST"
NOPARALLEL
drop table "SUK"."SYS_JOURNAL_10499"
我们在查查10499是什么东西：
SQL SELECT OBJECT_NAME,OBJECT_TYPE FROM DBA_OBJECTS WHERE OBJECT_ID=10499;
OBJECT_NAME OBJECT_TYPE
------------------------------ ------------------
IDX_TEST_C1 INDEX
从这些信息可以推测：表SYS_JOURNAL_10499就是实现在重建索引时不阻塞DML操作而设计的，它存储的是在索引重建期间发生在基表的数据变化。可以推测，CREATE INDEX .... ONLINE应该也有一张类似的表。
实际上，oracle之所以在创建索引时锁表阻止DML操作就是为了防止不能索引新变化的数据，在online方式重建时，有了临时表SYS_JOURNAL_XXXX，oracle就可以放心大胆地让用户操作了，因为所有重建索引期间的数据变化信息都会保留在SYS_JOURNAL_XXX表中，当索引重建完后再加上SYS_JOURNAL_XXX记录的数据，就不会漏索引数据了。（XXX是被重建的索引对应的OBJECT_ID)
导读：
重建索引有多种方式，如drop and re-create、rebuild、rebuild online等。下面简单比较这几种方式异同以及优缺点：
相关文章：
oracle重建索引（一）
oracle重建索引（二）
三、rebuild和rebuild online的数据源
网上一直有这样一个说法：重建索引是以原索引作为数据源的。那么，这种说法是否准确呢？我们做实验来验证一下：
suk@ORACLE9I COL SEGMENT_NAME FORMAT A30
--首先看看表和索引的大小
suk@ORACLE9I SELECT SEGMENT_NAME,BYTES FROM USER_SEGMENTS WHERE SEGMENT_NAME IN ('TEST','IDX_TEST_C1');
SEGMENT_NAME BYTES
------------------------------ ----------
TEST 201326592
IDX_TEST_C1 293601280
suk@ORACLE9I EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD;
已解释。
suk@ORACLE9I SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已选择11行。
--从执行计划可以看出，当索引比表大时，rebuild索引用的数据源是基表。
suk@ORACLE9I EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD ONLINE;
已解释。
suk@ORACLE9I SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已选择11行。
--从执行计划可以看出，当索引比表大时，rebuild online索引用的数据源是基表。
--我们为TEST添加一列，使得表比索引大
suk@ORACLE9I ALTER TABLE TEST ADD(C2 CHAR(30) DEFAULT '1');
表已更改。
suk@ORACLE9I SELECT SEGMENT_NAME,BYTES FROM USER_SEGMENTS WHERE SEGMENT_NAME IN ('TEST','IDX_TEST_C
1');
SEGMENT_NAME BYTES
------------------------------ ----------
TEST 1476395008
IDX_TEST_C1 293601280
suk@ORACLE9I EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD;
已解释。
suk@ORACLE9I SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | INDEX FAST FULL SCAN| IDX_TEST_C1 | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已选择11行。
--从执行计划可以看出，当表比索引大时，执行计划已经改变，rebuild索引是以索引作为数据源的。
suk@ORACLE9I EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD ONLINE;
已解释。
suk@ORACLE9I SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已选择11行。
--从执行计划可以看出，当表比索引大时，rebuild online仍然以基表作为数据源。
rebuild模式下，因为表数据不会产生变化，oracle主要考虑性能问题，把更快扫描完成的段作为数据源。在上面的例子中，我们并没有对表进行分析，故oracle应该根据数据段的大小来决定那个作为数据源的。一般索引字段比较多，或者对索引字段的DML操作较多，可能会导致索引比表大，这时oracle就会使用基表作为新索引的数据源进行rebuild了。
而在rebuild online模式下，因为允许DML操作，而表数据变化的同时索引也会跟着变化，为了索引与基表数据的一致性，比如采用基表数据作为数据源，而不能用原索引数据作为数据源。
我们用反证法证明不能用原索引作为新索引的数据源。
例如：
T1发出rebuild online命令
T2删除某条数据，删数据的同时，oracle会自动维护了旧索引
T3扫描经过T2数据所在索引节点
T4插入一条记录，新记录对应的索引节点刚好重用了T2删除的数据对应的索引节点空间
如果是这样的话，新建的索引将不包含T4插入的记录的信息。所以，rebuild online情况下新索引的数据源不能是原索引。
rebuild online情况下，如果非用原索引作为新索引的数据源的话，用中间表记录索引变化的方法应该是可以实现的，但由于数据变化会同时引起索引变化的特定决定了这种方法将异常复杂及效率底下，所以oracle不考虑旧索引作为新索引的数据源是有道理的。
结论：
1、rebuild会阻塞对基表的DML操作，但不会影响rebuild期间查询对原有索引的使用。
2、rebuild的数据源可能是基表，也可能是原索引。取决于基表和原索引的大小，那个小，rebuild时就会用那个作为数据源。这也说明了网上盛传的rebuild以原索引作为数据库的说法是不完全正确的。
3、rebuild online运行用户在索引重建期间执行DML操作。
4、rebuild online的数据源是基表
Normal 0 7.8 pt 0 2 false false false MicrosoftInternetExplorer4
oracle 索引什么时候重建和重建方法讨论
分类：数据库技术 字号： 大大中中小小 索引什么时候需要重建和重建的方法
一提到索引，大家都知道，但是怎样建索引，什么时候重建索引，重建索引用什么方法，可能有的就不太清楚了，我根据一些资料简单的整理一点，如果哪里不对或是不妥请大家指点，希望大家有更好经验也share出来。
索引的目的是为了加快寻找数据的速度，但是如果对表经常做改动，则索引也会相应改动，时间长了，查询速度的效率就会降低，就有可能要重建索引，那么什么时候需要重建索引和用什么方法重建索引可能是大家关心的。
一. 索引在内部进行自身的管理以确保对数据行的快速访问。但是数据表中大量的活动会导致oracle索引动态地对自身的进行重新配置，这些配置包括三个方面：
1．索引分割
当新数据行产生的索引节点要建立在现有级别上时，出现此动作。
2．索引生成
在某些位置，索引达到此级索引的最大容量的时候，就会生成更深一级的索引结构。
3．索引节点的删除
你可能了解到，删除表中的数据行后，索引中相应的节点不会从物理意义上删除，也没有从索引中删除此项目。而是从逻辑上删除此索引项目，并在索引树中留下了一个“死“节点，当索引删除了叶节点或是生成了过深的的级别层次后，就需要进行重建。
二 索引的种类：
a.B-tree（B树）索引
b.压缩B树索引
c.Bitmap（位图）索引
d.函数索引
e.Reverse Key Index（反向键索引）
f.Index Organized Table（索引组织表）
三 下面分别对各种索引进行说明
在进行介绍前先说明几个术语：
高基数：简单理解就是表中列的不同值多
低基数：建单理解就是表中的列的不同值少
以删除的叶节点数量：指得是数据行的delete操作从逻辑上删除的索引节点的数量，要记住oracle在删除数据行后，将“死“节点保留在索引中，这样做可以加快sql删除操作的速度，因此oracle删除数据行后可以不必重新平衡索引。
索引高度：索引高度是指由于数据行的插入操作而产生的索引层数，当表中添加大量数据时，oracle将生成索引的新层次以适应加入的数据行，因此， oracle索引可能有4层，但是这只会出现在索引数中产生大量插入操作的区域。Oracle索引的三层结构可以支持数百万的项目，而具备4层或是更多层的需要重建。
每次索引访问的读取数：是指利用索引读取一数据行时所需要的逻辑I/O操作数，逻辑读取不必是物理读取，因为索引的许多内容已经保存在数据缓冲区，然而，任何数据大于10的索引都需要重建。
1. B-tree（B树）索引
是现代关系型数据库中最常用的索引。除了存储索引数据外，还存储一个行ID，用来指出该行其余数据存储在这个被索引表中的什么地方。该索引以一种数结构格式存储这些值。
Oracle建议如果表经过排序，当返回40%一下的数据时使用索引，如果高于40%则使用全表扫描，如果没有经过排序，则当返回7%以下时，使用索引。看表是否排序，可以看dba_indexes字典中的CLUSTERING_FACTOR列，如果与表占用的数据块数相近，则经过了排序，如果与行数相近，则没有排序。那么什么时候重建呢？我们可以利用analyze index …….. compute statistics 对表进行分析。然后察看dba_indexes中的blevel。这列是说明索引从根块到叶快的级别，或是深度。如果级别大于等于4。则需要重建，如下：
Select index_name,blevel from dba_indexeswhere blevel=4.
另一个从重建中受益的指标显然是当该索引中的被删除项占总的项数的百分比。如果在20%以上时，也应当重建，如下
SQLanlyze index ------ validatestructure
SQLselect(del_lf_rows_len/lf_rows_len)*100 from index_stats where 删除并从头开始建立索引。
b. 使用alter index -------- rebuild 命令重建索引
c. 使用alter index -------- coalesce命令重建索引。
下面讨论一下这三种方法的优缺点：
1).删除并从头开始建索引：方法是最慢的，最耗时的。一般不建议。
2).Alter index ---- rebuild 快速重建索引的一种有效的办法，因为使用现有索引项来重建新索引，如果客户操作时有其他用户在对这个表操作，尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题，alter index ------- rebuild online.但是,由于新旧索引在建立时同时存在，因此，使用这种技巧则需要有额外的磁盘空间可临时使用，当索引建完后把老索引删除，如果没有成功，也不会影响原来的索引。利用这种办法可以用来将一个索引以到新的表空间。
Alter index ------ rebuild tablespace -----。
这个命令的执行步骤如下：
首先，逐一读取现有索引，以获取索引的关键字。
其次，按新的结构填写临时数据段。
最后，一旦操作成功，删除原有索引树，降临时数据段重命名为新的索引。
需要注意的是alterindex ---rebuild 命令中必须使用tablespace字句，以保证重建工作是在现有索引相同的表空间进行。
3).alter index ----- coalesce 使用带有coalesce参数时重建期间不需要额外空间，它只是在重建索引时将处于同一个索引分支内的叶块拼合起来，这最大限度的减少了与查询过程中相关的潜在的加锁问题，但是，coalesce选项不能用来讲一个索引转移到其他表空间。
2．压缩B树索引
当B树索引基于大表时，尤其是当基于数据仓库或决策支持系统中的大表时，这些索引会耗费大量的存储空间，压缩（compressed）B树索引用来最大限度的减少某些类型的B树索引使用的空间。当一个B树索引得到压缩时，被索引的猎的重复出现就被消除掉，进而减少了存储索引的总的存储空间。例如：
压缩前：smith每次出现还要存储它的相关的rowid.
姓 关联rowid
smith AAABSOAAEAAAABTAAB
smith AAABSOAAEAAAABTAAC
smith AAABSOAAEAAAABTAAD
压缩后:smith项和rowid指存储一次。
smith AAABSOAAEAAAABTAAB,AAABSOAAEAAAABTAAB, AAABSOAAEAAAABTAAB
创建方法：
SQLcreate index index_name ontable_name(column_name)
tablespace tablespace_name
compress;
另一种方法：
SQLalter index index_name rebuildcompress;
3． itmap(位图)索引。
B树索引在数据具有高基数的列工作的最好，对于低基数的列，位图索引可能是更有效的选择。位图索引创建表行的一个二进制映像，并把映像存储在索引块中，这种类型的索引的DML操作少，长度大并且含有极少不同的值得列特别有用。位图索引不应当用在频繁发生insert,update,delete操作的表上，这些dml操作在性能方面的代价很高，因为，他们会引起位图级的加锁发生，而且要求动态的重建所有可能值的位图。为图索引最适合数据仓库和决策支持系统。
4．基于函数的索引
当把一个函数运用于被索引的列上时，该列德索引都变得无效，基于函数的索引就是为了解决这个问题。
5．反向键索引
是一种特殊类型的B树索引，在索引基于含有序数的列时使非常有用的，如果一个传统的B树索引基于一个含有这种数据的列，往往会产生许多级，由于B树索引有 4级以上的深度会降低性能，因此反向键索引更适合这种类型，反向键索引通过简单的烦象被索引的列中的数据来解决问题，他首先反向每个列键值的字节，然后在反向后的新数据上进行索引，而新数据在值的范围上的分布通常比原来的有序数更均匀。
6．索引组织表
由于B树、位图、反向键索引的使用而引起的性能将会导致这样的事实，这些索引中的项目直接指向索引基表中对应数据的行ID,这是从表行没有按任何特定的顺序来物理地存储表中检索表行的一种有效方法，这种表叫做堆表，oracle大多数表中以一种堆叠方式存储行数据，因为行以一种或多或少的随机方式被分配给表内的块，之所以出现这种随机性，是因为oracle在决定把一个行存储在何处时并不考虑改行的内容，oracle只是把该行存储在它从该表的freelist 上所发现的第一个块中。
如果希望按一种指定顺序来存储一个表的数据，就不能使用堆表，为此oracle提供了索引组织表，索引组织表不是存储一个指向行数据的其余部分存储在了何处的行的ID指针，而是把行数据全部存储在索引本身内，这产生了两个性能好处：
n 表行按索引顺序来存储。
n 使用B树索引时引起的先读取索引后读取表锁使用的额外I/O操作得到消除。
例如：
sqlcreate table emp
(last_name varchar2(9) primary key,
first_name varchar2(9),
hire_date date)
organization index tablespace users
pctthreshold 25
including first name
overflow tablespace qyl
mapping table;
所有索引组织表在将要作为索引基础的那一列上都必须有一个主键约束，索引组织表不能含有唯一性约束或是被聚簇。
下面说明各个参数的含义：
organization index：说明该表是索引组织表
pctthreshold :指定整个数据块的什么百分比要保持打开，以便存储一个与主键值相关联的行数据，其中主键值必须在0到50之间（50是默认值）
including : 指定在行长度超过pctthershold中所设置的大小时按那一列 把行分解成两段
overflow tablespace ：指定在行长度超过pctthreshold中设置的大小时行数的的另一部分存储到的表空间。
Mapping table:致使在创建索引组织表的位图索引时所必需的一个关联映像表的创建。
以上是我根据一些资料对索引的一个简单阐述，大家可能有不同的见解，希望对大家有帮助，那些不妥的地方还希望大家提出来。
参考资料：ocp困惑racle9i性能调整
oracle statspack 高性能调整技术
[@more@]
analyze index t_id_ind validate structure
select (del_lf_rows_len/lf_rows_len)*100 from index_stats
20%
b. 使用alter index t_id_ind rebuild 命令重建索引
c. 使用alter index t_id_ind coalesce命令重建索引。
alter indext_id_ind rebuild online.
但是,由于新旧索引在建立时同时存在，因此，使用这种技巧则需要有额外的磁盘空间可临时使用，当索引建完后把老索引删除，如果没有成功，也不会影响原来的索引。利用这种办法可以用来将一个索引以到新的表空间。
Alter index ------ rebuild tablespace -----。
这个命令的执行步骤如下：
首先，逐一读取现有索引，以获取索引的关键字。
其次，按新的结构填写临时数据段。
最后，一旦操作成功，删除原有索引树，降临时数据段重命名为新的索引。
需要注意的是alter index ---rebuild 命令中必须使用tablespace字句，以保证重建工作是在现有索引相同的表空间进行
alter index ----- coalesce 使用带有coalesce参数时重建期间不需要额外空间，它只是在重建索引时将处于同一个索引分支内的叶块拼合起来，这最大限度的减少了与查询过程中相关的潜在的加锁问题，但是，coalesce选项不能用来讲一个索引转移到其他表空间
创建索引语法：
CREATE [UNIQUE] | [BITMAP] INDEX index_name
--unique表示唯一索引
ON table_name([column1 [ASC|DESC],column2
--bitmap，创建位图索引
[ASC|DESC],…] | [express])[TABLESPACE tablespace_name][PCTFREE n1]
--指定索引在数据块中空闲空间
[STORAGE (INITIAL n2)][NOLOGGING]
--表示创建和重建索引时允许对表做DML操作，默认情况下不应该使用
[NOLINE][NOSORT];
--表示创建索引时不进行排序，默认不适用，如果数据已经是按照该索引顺序排列的可以使用
扩展资料：
1、如果有两个或者以上的索引，其中有一个唯一性索引，而其他是非唯一，这种情况下oracle将使用唯一性索引而完全忽略非唯一性索引
2、至少要包含组合索引的第一列（即如果索引建立在多个列上，只有它的第一个列被where子句引用时，优化器才会使用该索引）
3、小表不要简历索引
4、对于基数大的列适合建立B树索引，对于基数小的列适合简历位图索引
5、列中有很多空值，但经常查询该列上非空记录时应该建立索引
6、经常进行连接查询的列应该创建索引
7、使用create index时要将最常查询的列放在最前面
8、LONG（可变长字符串数据，最长2G）和LONG RAW（可变长二进制数据，最长2G）列不能创建索引
9、限制表中索引的数量（创建索引耗费时间，并且随数据量的增大而增大；索引会占用物理空间；当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，降低了数据的维护速度）
用rebuile语句即可啊
Alter indexindex_name rebuild;
Alter indexindex_name rebuild online;
也可以把索引删除了重新建立
drop index indexindex_name;
create index indexindex_name on table_name(col_name);
