PostgreSQL 平时没事，怎么就一个SQL下去就不行了？，原来是老毛病了！

AustinDatabases 2025-12-31

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

PostgreSQL有一个大坑，但我之前没有想到这么的厉害，也为此吃了一个大亏，我就想请问了PostgreSQL官方你那个官方在设计PostgreSQL当前的模式中，有没有想过这个问题。

事情是这样的，最近一个数据库上跑了一个查询，查询一个月的数据，这些数据经常被UPDATE，且单表也到了50G左右，索引都添加了，平时虽然有IO的波动，但是还可以接受，直到矛盾爆发的一天，还是那个SQL下去后，磁盘瞬间每秒200多MB/S，最高接近了300MB/S。系统性能瞬间降低，影响了其他的SQL运行。

后续业务和我们进行分析，为什么平时都还好，但是现在不OK了，因为无论从条件和返回的数据量以及扫描的执行计划的行数等等都和平时无异议。

PG的其他问题都是小事，但突然来一次莫名其妙的“big problem”的确让人，匪夷所思。后来在查到一个指标的时候，才明白这和PG的本身的缺陷有关。

这个PG性能杀手就是，低密度页。首先解释什么叫低密度页，如果一个8KB的数据页面里面，频繁进行更新，就会制造大量的本来在本页面的行，因为PG的原理MVCC的原因，而数据放置在其他的页面，甚至是数据文件最后。

这就导致一个读放大的问题，在一些以BTREE为基础的数据组织的数据库中即使及在更新数据，他的数据位置还是在原来的位置，主要是数据的主键像锚钉一样，将数据的物理位置焊死。

PG是HEAP，堆表的形式，让一个表中的数据会出现在整体数据文件的不同的位置，导致为了获得很少的行数，而读取更多的额数据块，这叫做IO 放大。

而在PG的设计中，并未设计直接操控数据库服务器的磁盘系统，也就是IO的设计，整体读取数据都是依靠操作系统。当数据库发起数据读取的请求，操作系统内核会自动放大预读数据的窗口，因为在没有获得真正的数据之前，操作系统拿来的数据都需要进入数据库进行验证是否有需要的数据。

操作系统去调用数据文件，就是IOPS高的根本，且这样的效率并不高。

有人说，那我们不是有索引吗？这点我们还要说，PG的索引大小，有一些复合型的索引并不小，甚至有的比表本身都不小。在我们进行查询的时候，索引是需要进入到内存中，同时我们要注意，数据库历史上是一直痛恨，随机IO的，如果数据可以顺序读取，比跳跃式的读取的性能要高很多。

查看每个页面的行数

虽然上面的这个方案也无法能确定，一个SQL查询会涉及到多少页面，但是这里我们也有一个标准。

如果一个页面，只有10多行，那你这个IOPS在进行一些复杂的SQL提取数据的时候，一定不会很好，如果你的一个页面能放到到50-60行，那么你的查询IOPS的效率应该还是可以的，所以宽表，页面里面大量的varchar,(这里我们以不启用toast的标准进行考虑，每个varchar都不大，但就是多)，那么你的这个表的运行效率也不会很高。

同时这次的事情，也让我认识到，之前的一些认知的错误，PG无需进行分区表，单表承载力大的一些固有的对PG 的偏爱。总结，老毛病是治不了，但是对于PG的一些核心表

1 如果很大，可以进行分区的也可以考虑分区，但分区键要想好，不要到时候还有聚合的查询在等着

2 提升VACUUM 甚至一些情况的repack的操作，清理页面的碎片，让每个页面都有效利用。

3 如果真的要用POSTGRESQL ，且要在阿里云上，我们已经考虑 DUCKDB 了，阿里云支持 POSTGRESQL 后面挂一个DUCKDB 或者在RDS PG里面内嵌一个 DUCKDB。

最近作为阿里云的云数据库体验官，要来了一些福利，通过下面的链接，别人没有优惠的POSTGRESQL RDS 产品 + DUCKDB的组合，在这里只要7.5折扣。

https://www.aliyun.com/minisite/goods?userCode=qyua9rvi