pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
REINDEX — 重建索引
REINDEX { DATABASE | TABLE | INDEX } name [ FORCE ]
REINDEX根据表中存储的数据重建一个索引， 替换索引的旧副本。使用REINDEX的主要原因有 两个：
一个索引已经损坏，不再包含有效数据。尽管理论上这不应该发生， 但在实践中，索引可能因软件缺陷或硬件故障而损坏。 REINDEX提供了一种恢复方法。
该索引包含大量未被回收的死索引页。在 PostgreSQL中，B-tree 索引在某些 访问模式下可能出现这种情况。REINDEX提供了 一种通过写入不含死页的新版本索引来减少索引空间占用的方法。 更多信息见第 21.2 节。
DATABASE重建指定数据库的所有系统索引。用户表上的索引不被处理。 此外，共享系统目录上的索引也会被跳过（独立模式除外，见下文）。
TABLE重建指定表的所有索引。如果该表有次级“TOAST”表， 该表也会被重建索引。
INDEX重建一个指定的索引。
name要重建索引的特定数据库、表或索引的名称。表名和索引名可以是 模式限定的。
FORCE这是一个已废弃的选项；如果指定它将被忽略。
如果你怀疑用户表上的某个索引损坏了，可以简单地用 REINDEX INDEX或REINDEX TABLE重建该索引或该表的所有索引。处理损坏的用户表 索引的另一种方法就是删除并重新创建它。如果你希望在此期间 维持表面上正常的表操作，这实际上可能更可取。 REINDEX获取表的排他锁，而CREATE INDEX只锁定表的写而不锁定读。
如果你需要从系统表索引的损坏中恢复，事情就更困难了。在这种 情况下，重要的是系统自身没有使用过任何可疑的索引。（事实上， 在这种场景下你可能会发现服务器进程在启动时立即崩溃，因为 依赖了损坏的索引。）要安全地恢复，服务器必须以 -P选项启动，该选项阻止它在系统目录查找中 使用索引。
做到这一点的一种方法是关闭 postmaster，然后启动一个独立的 PostgreSQL服务器， 并在其命令行中包含-P选项。然后可以根据 你想重建多少，发出REINDEX DATABASE、 REINDEX TABLE或REINDEX INDEX。如果 不确定，使用REINDEX DATABASE来选择重建该数据库 的所有系统索引。然后退出独立服务器会话并重启常规服务器。 关于如何与独立服务器界面交互的更多信息，见 postgres参考页。
或者，可以在常规服务器会话的命令行选项中包含 -P来启动它。具体的做法因客户端而异，但在所有 基于libpq的客户端中，都可以在启动客户端之前 把PGOPTIONS环境变量设置为-P。 注意，虽然这种方法不需要锁定其他客户端，但在修复完成之前， 阻止其他用户连接到受损的数据库可能仍是明智的。
如果怀疑任何共享系统目录（pg_database、 pg_group或 pg_shadow）的索引损坏，则必须使用 独立服务器来修复。REINDEX在多用户模式下不处理 共享目录。
对于除共享系统目录之外的所有索引，REINDEX是崩溃 安全且事务安全的。REINDEX对共享索引不是崩溃安全 的，这就是正常操作期间禁止这种情况的原因。如果在独立模式下 重建这些目录之一时发生故障，在问题得到纠正之前将无法重启 常规服务器。（部分重建的共享索引的典型症状是“index is not a btree”错误。）
在PostgreSQL 7.4 之前， REINDEX TABLE不会自动处理 TOAST 表，因此必须用单独的命令重建 这些表的索引。现在仍然可以这样做，但已是多余的。
重建表my_table上的索引：
REINDEX TABLE my_table;
重建单个索引：
REINDEX INDEX my_index;
重建特定数据库中的所有系统索引，不信任它们已经是有效的：
$export PGOPTIONS="-P"$psql broken_db... broken_db=> REINDEX DATABASE broken_db; broken_db=> \q
SQL 标准中没有REINDEX命令。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。