24.2. 日常重建索引
在某些情況下值得周期性地使用
REINDEX指令或一系列獨立重構步驟來重建索引。
已經完全變成空的B樹索引頁面被收回重用。但是，還是有一種低效的空間利用的可能性：如果一個頁面上除少量索引鍵之外的全部鍵被删除，該頁面仍然被配置設定。是以，在這種每個範圍中大部分但不是全部鍵最終被删除的使用模式中，可以看到空間的使用是很差的。對于這樣的使用模式，推薦使用定期重索引。
對于非B樹索引可能的膨脹還沒有很好地定量分析。在使用非B樹索引時定期監控索引的實體尺寸是個好主意。
還有，對于B樹索引，一個建立立的索引比更新了多次的索引通路起來要略快， 因為在建立立的索引上，邏輯上相鄰的頁面通常實體上也相鄰（這樣的考慮目前并不适用于非B樹索引）。僅僅為了提高通路速度也值得定期重索引。
在所有情況下都可以安全和容易地使用。但是由于該指令要求一個排他表鎖，是以更好的方法是用一個由建立和替換步驟組成的序列來執行索引重建。支援帶
CONCURRENTLY
選項的
CREATE INDEX的索引類型可以用這種方式重建。如果建立成功并且得到的索引是可用的，則原來的索引可以使用
ALTER INDEX和
DROP INDEX的指令組合替換成新建立的索引。當一個索引被用于強制唯一性或者其他限制時，可能需要用
ALTER TABLE将現有的限制換成由新索引所強制的限制。在使用這種多步重建方法之前應仔細地檢查，因為對于哪些索引可以采用這種方法重索引是有限制的，并且出現的錯誤必須被處理。
本文轉自PostgreSQL中文社群，原文連結：
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)