9.3 9.4 9.5 9.6 10 11 12 13 14 Current(15)
阿里云PostgreSQL 问题报告 纠错本页面

23.2. 经常重建索引

有时候我们值得用REINDEX 命令或一系列单独的重建步骤周期性重建索引。

已经完全空的B树索引页会回收重新使用。然而,这可能是空间使用低效: 如果所有,但页面上的几个索引键已经被删除而页面仍分配。因此,使用模式其中大多数,但不是全部, 最终被删除的每个范围内的键将看到空间低效使用。对于这样的使用模式,推荐周期性重建索引。

对于非B-tree索引的膨胀潜能可能还没有很好地分析。 在使用非B-tree索引的时候保持对索引的物理尺寸的周期性监控是个很好的主意。

还有,对于B-tree索引,一个新建立的索引从某种意义上比更新了多次的访问起来稍微要快, 因为在新建立的索引上,逻辑上连接的页面通常物理上也连接在一起 (这样的考虑目前并不适用于非B-tree索引)。仅仅从提高访问速度角度出发, 可能我们也值得周期性的重建索引。

REINDEX可以在所有情况下安全简单的使用。 但是由于该命令请求了一个表上的独占锁,通常最好是用一系列创建和替换步骤执行索引重建。 支持带有CONCURRENTLY选项的CREATE INDEX 的索引类型可以用那种方法重建。如果成功了并且生成的索引是有效的, 那么可以使用ALTER INDEXDROP INDEX 的组合,用新建立的索引替换原来的索引。当一个索引用于强制唯一或其他约束时, ALTER TABLE用必要交换现有约束和新索引强制的约束。 在使用它之前,仔细的回顾这个交替多步骤重建方法, 因为这个方法重建索引有一些限制,并且错误必须被处理掉。

<
/BODY >