注意： 索引重建前建議把數據庫切換為完整模式，否則索引復制會在數據文件中進行，導致數據文件很大，而數據文件的收縮比日志文件的收縮要困難的多，且會對業務造成影響。 步驟一: 查詢索引碎片，腳本如下，庫比較大時執行時間會很長，雖然對數據庫影響不大，依然建議在非高峰時段執行。（執行之前請先選定要查詢碎片的數據庫） 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)之和與和表的總行數比較一下就可以大致知道目前的進度了。 注意由于每個任務分配的行數并不均勻，所以估算的結果不是很精確，不過一般不會太離譜。

轉載于:https://www.cnblogs.com/leohahah/p/7652410.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的SQL Server 索引重建手册的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。