数据库索引重建之后，碎片率再次提高

update/delete/insert *** 作，收缩文件，填充因子不合理，索引键设计不合理等造成的。

如果按照楼主说的，你可以定位一下究竟是什么原因造成的。系统是否频繁执行update/delete/insert *** 作，收缩文件之类的。另外索引的设计不合理这个也得重视。

SELECT object_name(dt.object_id) Tablename,si.name

IndexName,dt.avg_fragmentation_in_percent AS

ExternalFragmentation,dt.avg_page_space_used_in_percent AS

InternalFragmentation

FROM

(

SELECT object_id,index_id,avg_fragmentation_in_percent,avg_page_space_used_in_percent

FROM sys.dm_db_index_physical_stats (db_id('DB_DJSMS'),null,null,null,'DETAILED'

)

WHERE index_id <>0) AS dt INNER JOIN sys.indexes si ON si.object_id=dt.object_id

AND si.index_id=dt.index_id AND dt.avg_fragmentation_in_percent>10

AND dt.avg_page_space_used_in_percent<75 ORDER BY avg_fragmentation_in_percent DESC

--索引碎片信息

--使用下面的规则分析结果 你就可以找出哪里发生了索引碎片

--1)ExternalFragmentation的值>10表示对应的索引发生了外部碎片

--2)InternalFragmentation的值<75表示对应的索引发生了内部碎片

--如何整理索引碎片

--有两种整理索引碎片的方法

--1)重组有碎片的索引执行下面的命令

ALTER INDEX ALL ON TableName REORGANIZE

--2)重建索引执行下面的命令

ALTER INDEX ALL ON TableName REBUILD WITH (FILLFACTOR=90,ONLINE=ON)

--也可以使用索引名代替这里的ALL关键字重组或重建单个索引 也可以使用SQL Server管理工作台进行索引碎片的整理

使用SQL Server管理工作台整理索引碎片

什么时候用重组什么时候用重建呢?

当对应索引的外部碎片值介于10-15之间内部碎片值介于60-75之间时使用重组其它情况就应该使用重建

值得注意的是重建索引时索引对应的表会被锁定但重组不会锁表因此在生产系统中对大表重建索引要慎重因为在大表上创建索引可能会花几个小时

幸运的是从SQL Server 2005开始微软提出了一个解决办法在重建索引时将ONLINE选项设置为ON这样可以保证重建索引时表仍然可以正常使用

虽然索引可以提高查询速度但如果你的数据库是一个事务型数据库大多数时候都是更新 *** 作更新数据也就意味着要更新索引

这个时候就要兼顾查询和更新 *** 作了因为在OLTP数据库表上创建过多的索引会降低整体数据库性能

如果你的数据库是事务型的平均每个表上不能超过5个索引 如果你的数据库是数据仓库型平均每个表可以创建10个索引都没问题