↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。

受支持版本: 当前版本 (18) / 17 / 16 / 15 / 14
测试与开发版本: 19 / devel
不受支持的版本: 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 已于 2007 年 11 月结束社区维护,本页译文保留供仍在使用旧版本的读者参考。新系统请看当前版本。

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 中没有。

提交更正

译文有误、术语不当或页面显示问题,请到译文仓库 pgsty/pgdoc 报告译文问题。英文原文本身的问题,请在当前版本的对应页面向上游反馈;上游不再修订已结束维护的版本。