SQL Server 的維護計畫是很多 DBA 的好幫手，但時常就會看到很多人在使用「重建索引」常會弄錯的一些小細節
在使用 SQL Server 的時候，對資料庫管理人員來說，維護計畫實在是一個很棒的工具，只要拖拉一些 Task 進來之後，做好一些設定和調整先後順序，再配合好 SQL Agent 的排程，就可以很容易完成一些基礎的維護了。
在過去幾年的時間了，曾經有好幾次遇到一些公司的資料庫中，因為有些資料表的索引選擇不恰當，或者是資料表異動頻繁，為了降低資料表的破碎程度，會在執行計畫裡面加入「重建索引」的工作，只是很多時候都會看到一些常發生誤解，造成設定錯誤的狀況，因此想說整理一下，免得下次遇到有人設定錯誤，還要花時間來做解釋。
以下我先用 SQL Server 2014 的畫面來做解釋
1. 每頁可用空間：這是我比較常看到有人搞錯的地方，很多人都知道資料庫建立索引的時候，或者是維護索引的時候，可以加入填滿因素( Fill Factor )，用來指定每個分葉層級頁面上可用來放置資料的百分比，但是在這裡的每頁可用空間，是跟填滿因素剛好相反。因此如果您是類似圖上的設定為 20 ，那其實就是 Fill Factor = 80 的意思了。而我遇到過好幾個不同公司的 MIS，卻把那個參數當成填滿因素去設定，而造成重建索引完之後，整個資料庫會虛胖很多，造成資料庫效能反而被得很糟糕。
2. 索引保留為線上：而這個是我覺得另外一個很容易被搞錯的地方，就是這個 ONLINE = ON 的參數。很多朋友看到這個選項，都會被這個部份給勾選，想說當建立索引的時候，讓舊的索引還可以保持運作，避免引響線上的使用者。但是卻沒有注意到，這個下面有個預設值，如果系統不支援的話，那就不要重建索引。我們很多朋友他們沒有去注意，其實那個說穿了就是只有支援 Enterprise 的版本，如果您是使用 Standard 版本的話，這等於設定了這個之後，就不會去重建索引了。
從 SQL Server 2017 開始，SQL Server 針對「重建索引」，又增加了一塊索引統計資料選項，這真的是太貼心了。有這些新的選項就不用像之前的時候，只能自己把這些放到 SSIS 裡面去下指令，將索引的實體統計資訊先取出來之後，再去判斷要用重建索引還是重組索引，不去用那些現成的 Task 去做。要不然就是都不去管它，就全部都用重建索引，浪費比較多的時間去處理。現在有了這些之後，就可以針對真正比較大的索引，當破碎超過一定之後才去重建，把時間和資源放在真正的刀口上。
