PostgreSQL 9.4.4 中文手册 | |||
---|---|---|---|
上一页 | 上一级 | 章 23. 日常数据库维护工作 | 下一页 |
有时候我们值得用REINDEX 命令或一系列单独的重建步骤周期性重建索引。
已经完全空的B树索引页会回收重新使用。然而,这可能是空间使用低效: 如果所有,但页面上的几个索引键已经被删除而页面仍分配。因此,使用模式其中大多数,但不是全部, 最终被删除的每个范围内的键将看到空间低效使用。对于这样的使用模式,推荐周期性重建索引。
对于非B-tree索引的膨胀潜能可能还没有很好地分析。 在使用非B-tree索引的时候保持对索引的物理尺寸的周期性监控是个很好的主意。
还有,对于B-tree索引,一个新建立的索引从某种意义上比更新了多次的访问起来稍微要快, 因为在新建立的索引上,逻辑上连接的页面通常物理上也连接在一起 (这样的考虑目前并不适用于非B-tree索引)。仅仅从提高访问速度角度出发, 可能我们也值得周期性的重建索引。
REINDEX可以在所有情况下安全简单的使用。 但是由于该命令请求了一个表上的独占锁,通常最好是用一系列创建和替换步骤执行索引重建。 支持带有CONCURRENTLY选项的CREATE INDEX 的索引类型可以用那种方法重建。如果成功了并且生成的索引是有效的, 那么可以使用ALTER INDEX和DROP INDEX 的组合,用新建立的索引替换原来的索引。当一个索引用于强制唯一或其他约束时, ALTER TABLE用必要交换现有约束和新索引强制的约束。 在使用它之前,仔细的回顾这个交替多步骤重建方法, 因为这个方法重建索引有一些限制,并且错误必须被处理掉。