REINDEX

重建索引。

概要

REINDEX {INDEX | TABLE | DATABASE | SYSTEM} name

描述

REINDEX 使用索引的表里存储的数据重建一个索引,并且替换该索引的旧拷贝。有一些场景需要使用 REINDEX:

  • 一个索引变得 “臃肿”,其中包含很多空的或者近乎为空的页面。 HashData 数据库中的 B-树索引在特定的非常规访问模式下可能会发生这种情况。REINDEX 提供了一种方法来减少索引的空间消耗,即制造一个新版本的索引,其中没有死亡页面。
  • 修改了一个索引的存储参数(例如填充因子),并且希望确保这种修改完全生效。

参数

INDEX

重新创建指定的索引。

TABLE

重新创建指定表的所有索引。如果该表有一个二级 “TOAST” 表,它也会被重索引。

DATABASE

重新创建当前数据库内的所有索引。共享的系统目录上的索引也会被处理。这种形式的 REINDEX 不能在一个事务块内执行。

SYSTEM

重新创建当前数据库中在系统目录上的所有索引。共享系统目录上的索引也被包括在内。用户表上的索引则不会被处理。这种形式的 REINDEX 不能在一个事务块内执行。

name

要被重索引的特定索引、表或者数据库的名字。索引和表名可以被方案限定。当前,REINDEX DATABASE 和 REINDEX SYSTEM 只能重索引当前数据库,因此它们的参数必须匹配当前数据库的名称。

注解

REINDEX 类似于删除索引并且重建索引,在其中索引内容会被从头开始建立。不过,锁定方面的考虑却相当不同。 REINDEX 会用锁排斥写,但不会排斥在索引的父表上的读。它也会在被处理的索引上取得一个排他锁,该锁将会阻塞对该索引的使用尝试。相反,DROP INDEX 会暂时在父表上取得一个排他锁,阻塞写和读。 后续的 CREATE INDEX 会排斥写但不排斥读,由于该索引不存在,所以不会有读取它的尝试,这意味着不会有阻塞但是读操作可能被强制成昂贵的顺序扫描。

重索引单独一个索引或者表要求用户是该索引或表的拥有者。重索引一个数据库要求用户是该数据库的拥有者(注意拥有者因此可以重建由其他 用户拥有的索引或者表)。当然,超级用户总是能够重索引任何东西。

如果怀疑共享全局系统表目录索引已经损坏,它们只能在 HashData 数据库的 utility 模式下进行重建索引。损坏一个共享索引的典型症状会出现 “index is not a btree” 的错误,或者服务器在启动的时候由于依赖在已经损坏的索引上而立即崩溃。在这种情况下,联系 HashData 客服支持获取帮助。

示例

重建一个单独的索引:

REINDEX INDEX my_index;

重建表 my_table 上的所有索引:

REINDEX TABLE my_table;

兼容性

在 SQL 标准中没有 REINDEX 命令。

另见

CREATE INDEX, DROP INDEX, VACUUM

上级主题: SQL命令参考

results matching ""

    No results matching ""