NAME

       REINDEX - 重建索引

SYNOPSIS

       REINDEX { DATABASE | TABLE | INDEX } name [ FORCE ]

DESCRIPTION 描述

       REINDEX 基於存儲在表上的數據重建索引， 替換舊的索引拷貝。使用 REINDEX 有兩個主要原因：

       ·
          索引崩潰，並且不再包含有效的數據。儘管理論上這是不可能發生的，
         但實際上索引會因爲軟件毛病或者硬件問題而崩潰。REINDEX 提供了一個恢復方法。

       · 要處理的索引包含大量無用的索引頁未被回收。在某些情況下，  這個問題會發生  在  PostgreSQL
         裏面的                B-樹索引上。REINDEX                 提供了一個縮小索引空間消耗的方
         法，它採用的方法是寫一個不帶無用索引頁的新版本的索引。   參閱Section   21.2    ``Routine
         Indexing'' 獲取更多信息。

PARAMETERS 參數

       DATABASE
               恢復一個聲明瞭的數據庫的所有系統索引。
              不包含用戶表上的索引。同樣，除非在獨立運行模式下，也會忽略在共享系統表上的索引（見下文）。

       TABLE
               重新建立聲明的表的所有索引。如果表有個從屬的"TOAST"表，那麼這個表也會重新索引。

       INDEX
               重新建立聲明瞭的索引。

       name
               要重建的所聲明的數據庫/表/索引的名稱。 表和索引名可以有模式修飾。

       FORCE
               這是一個廢棄的選項，如果聲明，會被忽略。

NOTES 注意

        如果你懷疑一個用戶表上的索引崩潰了，你可以簡單地重建該索引，   或者該表上地所有索引，使用
       REINDEX               INDEX               或者               REINDEX               TABLE。
       另外一個對付用戶表索引崩潰的方法時刪除然後重建它。如果你還要在表上進行一些維護動作，
       可能這麼做更好一些。REINDEX    在表上請求排他鎖，而    CREATE    INDEX    只是鎖住寫動作，
       而不會鎖住讀。

        如果你從一個崩潰的系統表索引上恢復，事情會更棘手一些。
       這種情況下，系統必須不能使用任何有疑問的索引。
       （實際上，在這種情況下，你可能發現服務器進程在啓動之後馬上就崩潰了，
       因爲依賴於崩潰了的索引。）要想安全恢復，服務器必須帶着            -P            選項啓動，
       它禁止服務器在查找系統表的時候使用索引。

        這麼做個一個辦法事停止   postmaster   然後帶着   -P  命令行選項啓動一個獨立的  PostgreSQL
       服務器。  然後，根據你希望恢復的程度，可以發出   REINDEX   DATABASE，REINDEX   TABLE，或者
       REINDEX  INDEX。  如果還有懷疑，使用 REINDEX DATABASE 選擇重新構造數據庫中全部的系統索引。
       然後退出獨立服務器會話並且重啓普通的服務器。參閱                               postgres(1)
       手冊頁獲取有關如何與獨立服務器交互的信息。

        另外，一個普通的會話可以在其命令行選項裏帶着                   -P                  啓動。
       這麼做的方法因不同的客戶端而異，但是在所有基於             libpq              的客戶端上，
       我們都可以通過在啓動客戶端之前設置       PGOPTIONS       環境變量爲       -P      來實現。
       請注意儘管這個方法並不要求鎖住其它客戶端，但是禁止其它客戶端連接受損的數據庫，
       直到完成修補應該事一個明智的選擇。

        如果懷疑任何共享的系統表的索引損壞（(pg_database，      pg_group，或者      pg_shadow），
       那麼必須用獨立服務器的方式來修復它。REINDEX 不能在多用戶環境下處理共享系統表。

        除了共享系統表之外的所有索引，REINDEX         是抗崩潰並且是事務安全的。          REINDEX
       對於共享的索引而言不是抗崩潰的，這就是爲什麼不允許在正常操作中這麼使用的原因。
       如果在重新對一個共享表進行索引的時候發生了崩潰，那麼在糾正問題之前，就不可能重新啓動普通的服務器。
       （一個建立了一部分的共享索引的典型症狀是"index is not a btree/索引不是 btree 索引"錯誤。）

        在       PostgreSQL       7.4       之前，REINDEX      TABLE      並不自動處理      TOAST
       表，因此這些表必須用獨立的命令進行處理。這麼做仍然可以，但是已經多餘了。

EXAMPLES 例子

        重建表 mytable 上的索引：

       REINDEX TABLE my_table;

        重建單個索引：

       REINDEX INDEX my_index;

        重建一個數據庫上的所有系統索引，不管他們是否有效：

       $export PGOPTIONS="-P"
       $psql broken_db
       broken_db=> REINDEX DATABASE broken_db;
       broken_db=> \q

COMPATIBILITY 兼容性

        在SQL 標準裏沒有 REINDEX。

譯者

       Postgresql 中文網站 何偉平 <laser@pgsqldb.org>

跋

       本頁面中文版由中文 man 手冊頁計劃提供。
       中文 man 手冊頁計劃：https://github.com/man-pages-zh/manpages-zh