注意：
索引重建前建议把数据库切换为完整模式，否则索引复制会在数据文件中进行，导致数据文件很大，而数据文件的收缩比日志文件的收缩要困难的多，且会对业务造成影响。
步骤一:
查询索引碎片，脚本如下，库比较大时执行时间会很长，虽然对数据库影响不大，依然建议在非高峰时段执行。（执行之前请先选定要查询碎片的数据库）
Declare @dbid int
Select @dbid=DB_ID()
SELECT DB_NAME(ps.database_id) AS [Database Name], OBJECT_NAME(ps.OBJECT_ID) AS [Object Name],
i.name AS [Index Name], ps.index_id, ps.index_type_desc, ps.avg_fragmentation_in_percent,
ps.fragment_count, ps.page_count, i.fill_factor, i.has_filter, i.filter_definition
FROM sys.dm_db_index_physical_stats(@dbid,NULL, NULL, NULL,null) AS ps
INNER JOIN sys.indexes AS i WITH (NOLOCK)
ON ps.[object_id] = i.[object_id]
AND ps.index_id = i.index_id
WHERE ps.database_id = DB_ID()
AND ps.index_type_desc <> 'HEAP'
AND ps.page_count > 2500
ORDER BY ps.avg_fragmentation_in_percent DESC OPTION (RECOMPILE);
步骤二:
筛选需要进行索引重建的表，举例如下：
一般来说，avg_fragmentation_in_percent大于60%就可以考虑重建了，因此本例中前10个索引都需要重建。其中index_id为1的表示是聚集索引（主键索引）。
步骤三:
！！！重要警告：操作前先备份全库，留后手永远是对自己和企业最大的负责。
索引重建的方式，我们一般采用在线重建的方式（SQL Server 2005之前的版本不支持），因此语句如下：
alter index index_name
on table_name
rebuild
with(online = on ,sort_in_tempDB = on , maxdop = 最大并行度);
go
在这里最大并行度应当选择操作系统CPU核数的80%为宜。
此外索引重建应当遵循以下原则：
- 为避免空间使用过多，应当对索引进行依次重建，不建议使用alter index all on table_name...的语句。
- 如果一个表有多个索引需要重建，则重建的顺序必须为：先重建聚集索引（即主键索引），再重建非聚集索引。
步骤四：
在在线重建索引的过程中，需要观察索引重建的进度，但是online索引重建的进度并不会在sys.dm_exec_requests中显示，因此微软提供了另一种查看完成进度的方式,具体如下：
在sql profiler的Progress Report中，可以监视Online Index Operation的情况。
其中BigintData1表示已经完成的在线重建记录数，BigData2表示当前线程的序列号，只要把所有进程的max(bigdata1)之和与和表的总行数比较一下就可以大致知道目前的进度了。
注意由于每个任务分配的行数并不均匀，所以估算的结果不是很精确，不过一般不会太离谱。
