↑↓ 选择↵ 打开⌫ 切换范围完整搜索

PG.CENTER 连接 PostgreSQL 文档、百科与生态知识。由 Pigsty 维护。

支持中的版本: 当前版本 (18) / 17 / 16 / 15 / 14
开发中的版本: 19 / 20devel
已结束支持的版本: 13 / 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3 / 7.2 / 7.1 / 7.0
历史版本。 PostgreSQL 7.3 已结束支持。 请参阅 当前版本手册.

REINDEX

REINDEX — 重建损坏的索引

大纲

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

输入

TABLE

重建指定表的所有索引。

DATABASE

重建指定数据库的所有系统索引。(不包括用户表上的索引。)

INDEX

重建一个指定的索引。

name

要重建索引的特定表/数据库/索引的名称。表名和索引名可以是模式限定的。

FORCE

强制重建系统索引。不带此关键字时,REINDEX将跳过未被标记为无效的系统索引。FORCE 对于REINDEX INDEX或者重建用户索引的情况没有作用。

输出

REINDEX

表成功重建索引后返回的消息。

描述

REINDEX用于重建损坏的索引。尽管理论上这永远不应该成为必要,但在实践中,索引可能因软件缺陷或硬件故障而损坏。REINDEX提供了一种恢复方法。

REINDEX还可以删除某些无法通过其他方式回收的死索引页。更多信息见手册中的“Routine Reindexing”(例行重建索引)一节。

如果你怀疑用户表上的某个索引已损坏,可以简单地使用 REINDEX INDEX或REINDEX TABLE 重建该索引或该表的所有索引。

注意

处理损坏的用户表索引的另一种方法就是删除并重新创建它。如果你希望在此期间维持表面上正常的表操作,这实际上可能更可取。REINDEX获取表的排他锁,而CREATE INDEX 只锁定表的写而不锁定读。

如果你需要从系统表索引的损坏中恢复,事情就更困难了。在这种情况下,重要的是执行恢复的后端自身没有使用过任何可疑的索引。(事实上,在这种场景下你可能会发现后端在启动时立即崩溃,因为它们依赖了损坏的索引。)要安全地恢复,必须关闭 postmaster,改为启动一个独立的PostgreSQL后端,并在它的命令行中给出选项 -O 和 -P(这两个选项分别允许修改系统表和阻止使用系统索引)。然后根据你想重建多少,发出 REINDEX INDEX、REINDEX TABLE或 REINDEX DATABASE。如果不确定,使用 REINDEX DATABASE FORCE强制重建该数据库中的所有系统索引。然后退出独立后端并重启 postmaster。

由于这可能是大多数人使用独立后端的唯一场合,这里给出一些用法提示也许有帮助:

  • 用类似下面的命令启动后端:

    postgres -D $PGDATA -O -P my_database

    用-D提供数据库区域的正确路径,或者确保已设置环境变量PGDATA。同时指定你想要在其中工作的特定数据库的名称。

  • 你可以发出任何 SQL 命令,而不仅是REINDEX。

  • 要注意,独立后端把换行符当作命令输入的终止符;它不像 psql那样对分号有智能处理。要把一个命令延续到多行,必须在除最后一个之外的每个换行符之前输入反斜线。此外,你也不会有任何命令行编辑的便利(例如没有命令历史)。

  • 要退出后端,输入EOF(通常是Control+D)。

更多信息见postgres参考页。

用法

重建表mytable上的索引:

     REINDEX TABLE mytable;
   

重建单个索引:

    REINDEX INDEX my_index;
   

重建所有系统索引(这只在独立后端中可行):

    REINDEX DATABASE my_database FORCE;
   

兼容性

SQL92

REINDEX 在 SQL92 中没有。

报告文档问题

阅读 上游文档. 反馈更正前请先核对 当前版本手册.