# REINDEX ## Name REINDEX?--?重建索引 ## Synopsis ``` REINDEX { INDEX | TABLE | DATABASE | SYSTEM } _name_ [ FORCE ] ``` ## 描述 `REINDEX`使用存儲在索引表中的數據重建索引，替換舊的索引的副本。 使用`REINDEX`有兩個主要原因： * 索引崩潰，并且不再包含有效的數據。盡管理論上這是不可能發生的， 但實際上索引會因為軟件毛病或者硬件問題而崩潰。`REINDEX`提供了一個恢復方法。 * 索引變得"臃腫"，包含大量的空頁或接近空頁。 這個問題在某些罕見訪問模式時會發生在 B-tree 索引上。`REINDEX` 通過寫一個不帶無用索引頁的新索引提供了縮小索引空間消耗的途徑。 參閱[Section 23.2](#calibre_link-1274)獲取更多信息。 * 為索引更改了存儲參數(例如填充因子)，并且希望這個更改完全生效。 * 使用`CONCURRENTLY`選項創建索引失敗，留下了一個"非法"索引。 這樣的索引毫無用處，但是可以通過`REINDEX`重建新索引來覆蓋。注意， `REINDEX`不能并發創建。要在生產環境中重建索引并且盡可能減小對尖峰負載的影響， 可以先刪除舊索引，然后使用`CREATE INDEX CONCURRENTLY`命令重建新索引。 ## 參數 `INDEX` 重新建立指定的索引。 `TABLE` 重新建立指定表的所有索引。如果表有從屬的"TOAST"表，那么這個表也會重新索引。 `DATABASE` 重建當前數據庫里的所有索引。也處理在共享系統表上的索引。 這種形式的`REINDEX`不能在事務塊中執行。 `SYSTEM` 在當前數據庫上重建所有系統表上的索引。包括在共享系統表上的索引。不會處理在用戶表上的索引。 這種形式的`REINDEX`不能在事務塊中執行。 `_name_` 需要重建索引的索引、表、數據庫的名稱。表和索引名可以有模式修飾。目前， `REINDEX DATABASE`和`REINDEX SYSTEM`只能重建當前數據庫的索引， 因此其參數必須匹配當前數據庫的名字。 `FORCE` 這是一個廢棄的選項，如果聲明，會被忽略。 ## 注意 如果你懷疑一個用戶表上的索引崩潰了，你可以簡單地使用`REINDEX INDEX` 重建該索引，或者使用`REINDEX TABLE`重建該表上的所有索引。 如果你從一個崩潰的系統表索引上恢復，事情會更棘手一些。這種情況下， 系統必須不能使用任何有疑問的索引。實際上，在這種情況下， 你可能發現服務器進程在啟動之后馬上就崩潰了，因為依賴于崩潰了的索引。要想安全恢復， 服務器必須帶著`-P`選項啟動，它禁止服務器在查找系統表的時候使用索引。 達到這個目的的一個方法是停止服務器然后帶著`-P` 命令行選項啟動一個獨立的PostgreSQL服務器。然后， 根據你希望恢復的程度，發出`REINDEX DATABASE`, `REINDEX SYSTEM`, `REINDEX TABLE`, `REINDEX INDEX`命令。如果還有懷疑， 使用`REINDEX SYSTEM`選擇重新構造數據庫中全部的系統索引。 然后退出獨立服務器會話并且重啟普通的服務器。參閱[postgres](#calibre_link-1033) 手冊頁獲取有關如何與獨立服務器交互的信息。 另外，一個普通的會話可以在其命令行選項里使用`-P`選項啟動。 這么做的方法因不同的客戶端而異，但是在所有基于libpq的客戶端上， 都可以通過在啟動客戶端之前設置`PGOPTIONS`環境變量為`-P`來實現。 請注意盡管這個方法并不要求鎖住其它客戶端，但是禁止其它客戶端連接受損的數據庫， 直到完成修補是一個明智的選擇。 `REINDEX`類似于刪除并重建索引，表現在它們都是從零開始重建。不過， 從鎖的角度考慮，兩者是有區別的。`REINDEX`鎖住對索引的父表的寫操作， 但是不鎖讀操作。并且它還在被處理的特定索引上保持一個排他鎖， 這樣它將阻止試圖使用該索引的讀操作。相比之下，`DROP INDEX` 在父表上短暫的保持一個排他鎖，同時鎖住讀和寫。隨后的`CREATE INDEX` 鎖住寫操作但是不會鎖住讀操作；因為索引還不存在，所以不會有試圖使用它的讀操作， 意味著操作中不會有阻塞，只不過讀操作會被迫只能使用順序掃描。 對一個索引或者表進行重建索引，要求你是該索引或者表的所有者。 對一個數據庫重建索引要求你是該數據庫的所有者(注意，可以重建其它用戶擁有的索引)。 當然，超級用戶總是可以重建所有索引。 PostgreSQL 8.1之前，`REINDEX DATABASE` 只處理系統索引，而不是人們從名字猜測的那樣，處理所有索引。這個行為現在已經改變了， 以減少意外的因素。舊的行為可以通過`REINDEX SYSTEM`獲得。 PostgreSQL 7.4之前，`REINDEX TABLE` 并不自動處理 TOAST 表，因此這些表必須用獨立的命令進行處理。這么做仍然可以， 但是已經多余了。 ## 例子 重建一個單獨的索引： ``` REINDEX INDEX my_index; ``` 重建表`my_table`上的所有索引： ``` REINDEX TABLE my_table; ``` 重建一個數據庫上的所有系統索引，不管系統索引是否仍然有效： ``` $ <kbd class="literal">export PGOPTIONS="-P"</kbd> $ <kbd class="literal">psql broken_db</kbd> ... broken_db=> REINDEX DATABASE broken_db; broken_db=> \q ``` ## 兼容性 SQL 標準里沒有`REINDEX`命令。