REINDEX
重建索引。
概要
REINDEX { INDEX | TABLE | DATABASE | SYSTEM} name
描述
REINDEX
使用索引的表里存储的数据重建一个索引, 并且替换该索引的旧拷贝。有一些场景需要使用REINDEX
:
- 一个索引变得“臃肿”,其中包含很多空的或者近乎为空的页面。Greenplum数据库中的B-树索引在特定的非常规访问模式下可能会发生这种情况。
REINDEX
提供了一种方法来减少索引的空间消耗,即制造一个新版本的索引,其中没有死亡页面。 - 修改了一个索引的存储参数(例如填充因子),并且希望确保这种修改完全生效。
参数
INDEX
重新创建指定的索引。
TABLE
重新创建指定表的所有索引。如果该表有一个二级“TOAST”表,它也会被重索引。
DATABASE
重新创建当前数据库内的所有索引。共享的系统目录上的索引也会被 处理。这种形式的REINDEX
不能在一个事务块内执行。
SYSTEM
重新创建当前数据库中在系统目录上的所有索引。共享系统目录上的 索引也被包括在内。用户表上的索引则不会被处理。这种形式的 REINDEX
不能在一个事务块内执行。
name
要被重索引的特定索引、表或者数据库的名字。索引和表名可以被方案限定。当前,REINDEX
DATABASE
和REINDEX SYSTEM
只能重索引当前数据库,因此它们的参数必须匹配当前数据库的名称。
注解
REINDEX
类似于删除索引并且重建索引,在其中 索引内容会被从头开始建立。 不过,锁定方面的考虑却相当不同。 REINDEX
会用锁排斥写,但不会排斥在索引的父表上的读。 它也会在被处理的索引上取得一个排他锁,该锁将会阻塞对该索引的使用尝试。相反,DROP INDEX
会暂时在父表上取得一个排他锁,阻塞写和读。 后续的CREATE INDEX
会排斥写但不排斥读,由于该索引不存在,所以不会有读取它的尝试,这意味着不会有阻塞但是读操作可能被强制成昂贵的顺序扫描。
重索引单独一个索引或者表要求用户是该索引或表的拥有者。重索引一个 数据库要求用户是该数据库的拥有者(注意拥有者因此可以重建由其他 用户拥有的索引或者表)。当然,超级用户总是能够重索引任何东西。
如果怀疑共享全局系统表目录索引已经损坏,它们只能在Greenplum数据库的utility模式下进行重建索引。损坏一个共享索引的典型症状会出现“index is not a btree”的错误,或者服务器在启动的时候由于依赖在已经损坏的索引上而立即崩溃。在这种情况下,联系Greenplum客服支持获取帮助。
示例
重建一个单独的索引:
REINDEX INDEX my_index;
重建表my_table
上的所有索引:
REINDEX TABLE my_table;
兼容性
在SQL标准中没有REINDEX
命令。
另见
[CREATE INDEX](CREATE_INDEX.html#topic1)
, [DROP INDEX](DROP_INDEX.html#topic1)
, [VACUUM](VACUUM.html#topic1)
上级主题: SQL命令参考