postgresql 数据库 重建索引 所需时间测试
文章目录
- postgresql 数据库 重建索引 所需时间测试
- 前言
- 测试前准备
- 重建索引前数据库状态
- 测试计划
- 重建索引命令
- 测试开始
- 1.先对表2进行测试
- 2. 表3测试
- 3. 表1测试
- 🌈后记
前言
众所周知，postgresql数据库使用久了，数据量更新大的表的索引会不断膨胀，需要重建索引来保证数据库的效率。那重建索引需要多长时间呢？
测试前准备
环境：
pg版本：11.5
系统：Linux
重建索引前数据库状态
查询数据库状态：
如图所示，上图这几个表的索引的大小已经比表中的数据量还大了，很明显索引已经膨胀了，这次我们来拿这三个表来测试一下，看看实验结果如何
测试计划
上图中表一，是一个拥有4亿数据量的表，索引已经占到了112G了，这个表我们来测试重建需要所花费多长的时间，表2和表3都是同一个分布表的子分区表，数据量也差不多，索引大小也一样，那这样打算，表2进行整表重建索引，表3进行单个索引单个索引的重建，看看他们相差多少时间。
先查看这三张表的索引数量：
表1：
表2：
表3：
本文章只针对测试重建索引，不对索引进行优化！！！
本文章只针对测试重建索引，不对索引进行优化！！！
本文章只针对测试重建索引，不对索引进行优化！！！
重建索引命令
REINDEX [ ( option [, ...] ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM }[ CONCURRENTLY ] namewhere option can be one of:CONCURRENTLY [ boolean ]TABLESPACE new_tablespaceVERBOSE [ 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
