为什么需要索引
?????? 大多数数据库表需要索引来对数据的实际访问速度进行提高，如果没有索引，查询时需要进行全表扫描读取表中的每一个记录才能找到索要的数据，所以，合适的索引，是提高数据库运行效率的一个很好的工具。索引类似于书的目录，相当于记录了对某个关键词，指定到不同的文件，或者文件里的不同位置，当然索引自身也是通过文件来保存的，这样，按条件查询的时候，先查询索引，再通过索引找到相关的数据。
????? 不过，并不是说表上的索引越多越好。过之而不及。故在数据库设计过程中，还是需要为表选择一些合适的索引。宁缺勿滥，这是建立索引时的一个遵循标准。在理论上，虽然一个表可以设置无限的索引。但是，数据库管理员需要知道，表中的索引越多，维护索引所需要的开销也就越大。每当数据表中记录有增加、删除、更新变化的时候，数据库系统都需要对所有索引进行更新。故数据库表中的索引绝对不是多多益善。按照一般的理论来说，当某个表多数用来查询、更新相对来说比较少的话，则要采用索引。相反，当某个表记录更新居主导，查询相对来说比较少的话，则不要建立太多的索引，避免对更新的速度差生不利影响。在实际工作中，若某个表频繁的被视图所调用的话，则最好就好设置比较多的索引了。建议：在表的更新速度与查询速度之间寻求一个平衡点
?
索引的分类
索引可以分为簇索引和非簇索索引
簇索引通过重排表中的数据来提高数据的访问速度，而非簇索引则通过维护表中的数据指针来提高数据的访问速度
?
为什么要不断的维护表的索引？首先，简单介绍一下索引的体系结构。
????? 例如sql server数据库在硬盘中用8KB页面在数据库文件内存放数据。缺省情况下这些页面及其包含的数据是无组织的。为了使混乱变为有序，就要生成索引。生成索引后，就有了索引页和数据页，数据页保存用户写入的数据信息。索引页存放用于检索列的数据值清单（关键字）和索引表中该值所在纪录的地址指针。索引分为簇索引和非簇索引，簇索引实质上是将表中的数据排序，就好像是字典的索引目录。非簇索引不对数据排序，它只保存了数据的指针地址。向一个带簇索引的表中插入数据，当数据页达到100%时，由于页面没有空间插入新的的纪录，这时就会发生分页，SQL Server将大约一半的数据从满页中移到空页中，从而生成两个半的满页。这样就有大量的数据空间。簇索引是双向链表，在每一页的头部保存了前一页、后一页地址以及分页后数据移动的地址，由于新页可能在数据库文件中的任何地方，因此页面的链接不一定指向磁盘的下一个物理页，链接可能指向了另一个区域，这就形成了分块，从而减慢了系统的速度。对于带簇索引和非簇索引的表来说，非簇索引的关键字是指向簇索引的，而不是指向数据页的本身。
为了克服数据分块带来的负面影响，需要重构表的索引，这是非常费时的，因此只能在需要时进行。
可以通过DBCC SHOWCONTIG来确定是否需要重构表的索引
以应用程序中的Employee数据表作为例子
输入命令
dbcc showconfig(table_id)
输出结果
查看一下相关区域中的页数
Scan Density [Best Count:Actual?? Count].......: 92.00% [23:25]
通过分析这些结果可以知道该表的索引是否需要重构
Count是连续链接时的理想区域改变数，Actual Count是实际区域改变数，Scan Density为100%表示没有分块
从上面命令的执行结果可以看的出来，Best count为23 而Actual Count为25这表明orders表有分块需要重构表索引。
下面通过DBCC DBREINDEX来重构表的簇索引
DBCC DBREINDEX
重建指定数据库中表的一个或多个索引
通过允许动态重建索引，可以重建强制 PRIMARY KEY 或 UNIQUE 约束的索引，而不必除去并重新创建这些约束。
这意味着不必知道表的结构或约束就可以重建索引，将数据大容量复制到表中后就会出现这种情况
语法 DBCC DBREINDEX ( [ ’database.owner.table_name’ [ , index_name [ ,fillfactor ] ] ] )
如果提供 database 或 owner 部分，则必须使用单引号 (’)将整个 database.owner.table_name 括起来
如果只指定 table_name，则不需要单引号
index_name 是要重建的索引名
如果未指定 index_name或指定为 ’’，就要对表的所有索引进行重建
fillfactor 是创建索引时每个索引页上要用于存储数据的空间百分比
如果 fillfactor 为 0，DBCC DBREINDEX 在创建索引时将使用默认值
如果指定 index_name 或 fillfactor，还必须指定以前所有的参数
?
???????? DBCC DBREINDEX 可以使用一条语句重建表的所有索引，这比对多个 DROP INDEX 和 CREATE INDEX 语句进行编码容易。由于该工作是通过一条语句完成的，所以 DBCC DBREINDEX 自动为原子性，而单个 DROP INDEX 和 CREATE INDEX 语句要成为原子性则必须放在事务中。另外，与使用单个 DROP INDEX 和 CREATE INDEX 语句相比，DBCC DBREINDEX 可从 DBCC DBREINDEX 的优化性能中更多地获益。
不支持在系统表上使用 DBCC DBREINDEX
?
示例
dbcc dbreindex(’database_name.dbo.Employee’,’’,90)
然后再用DBCC SHOWCONTIG查看重构索引后的结果
Scan Density [Best Count:Actual?? Count].......: 100.00% [23:23]
通过结果我们可以看到Scan Denity为100%
?
A. 重建某个索引
下例使用填充因子 80 重建 pubs 数据库中 authors 表上的 au_nmind 聚集索引。
DBCC DBREINDEX ('pubs.dbo.authors', UPKCL_auidind, 80)
?
B. 重建所有索引
下例使用填充因子值 70 重建 authors 表上的所有索引。
DBCC DBREINDEX (authors, '', 70)
?
sybase数据库
如果出现如下的提示：
Table id 1737054193 contains suspect indexes.
This table is only available for read-only purposes until the DBCC REINDEX command has been run on the indicated table to rebuild its suspect indexes.
执行命令
dbcc reindex (table_id)
即可！
