postgresql 数据库 重建索引 所需时间测试

postgresql 数据库 重建索引 所需时间测试

前言

众所周知，postgresql数据库使用久了，数据量更新大的表的索引会不断膨胀，需要重建索引来保证数据库的效率。那重建索引需要多长时间呢？

测试前准备

环境：
pg版本：11.5
系统：Linux

重建索引前数据库状态

查询数据库状态：

如图所示，上图这几个表的索引的大小已经比表中的数据量还大了，很明显索引已经膨胀了，这次我们来拿这三个表来测试一下，看看实验结果如何

测试计划

上图中表一，是一个拥有4亿数据量的表，索引已经占到了112G了，这个表我们来测试重建需要所花费多长的时间，表2和表3都是同一个分布表的子分区表，数据量也差不多，索引大小也一样，那这样打算，表2进行整表重建索引，表3进行单个索引单个索引的重建，看看他们相差多少时间。

先查看这三张表的索引数量：

表1：

表2：

表3：

本文章只针对测试重建索引，不对索引进行优化！！！
本文章只针对测试重建索引，不对索引进行优化！！！
本文章只针对测试重建索引，不对索引进行优化！！！

重建索引命令

REINDEX [ ( option [, ...] ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM }
 [ CONCURRENTLY ] name

where option can be one of:

    CONCURRENTLY [ boolean ]
    TABLESPACE new_tablespace
    VERBOSE [ boolean ]

REINDEX TABLE CONCURRENTLY table_name;

注意：
（REINDEX TABLE CONCURRENTLY pg11不支持，pg14支持）

测试开始

1.先对表2进行测试

REINDEX TABLE  "表2" ;

表2中数据19Gb，数据量79340800，（8千万） ，索引条数5，大小20Gb。

用时953.526s

重建索引后，表2的索引少了8G，还是很多，需要后续继续优化，用时953.526s。

2. 表3测试

reindex index     索引命名;

注：
由于pg11不支持reindex index 使用 CONCURRENTLY 参数，可能会有一些影响，可能会发生死锁等等。

结果

表3中数据19Gb，数据量78852500，（8千万） ，索引条数5，大小20Gb。


用时917.059

经过测试，发现2种方式所用时间相差不大。

3. 表1测试

因为数据库版本是pg11.5，不支持REINDEX 使用 CONCURRENTLY 参数，为了不影响业务，在对表1的操作中只能采用drop的方法，然后并行创建索引的方式。

表1中数据19Gb，数据量499677000，（50亿） ，索引条数3，大小112Gb。

共用时3960s

后记

如果本文章有何错误，请您评论中指出，或联系我，我会改正，如果您觉得这篇文章有用，请帮忙一键三连，让更多的人看见，谢谢
作者 yang_z_1 csdn博客地址： https://blog.csdn.net/yang_z_1?type=blog