POSTGRESQL 提高POSTGRESQL性能的一些习惯 （2）

接着上期，POSTGRESQL 的灵活性 和 本身的复杂性的确是可以在很多细节进行优化，本期从建表的角度来说说POSTGRESQL 优化地方。

1 宽表到底是不是一件好事情

POSTGRESQL 默认的一个页面的宽度是8KB，同时根据POSTGRESQL 本身对大型字段的扩展的方式TOAST，实际上有些项目的表设计本身会突破POSTGRESQL 本身的限制。我们可以从下图考到POSTGRESQL在表设计中的限制。

这说明两个问题， 1 你的表设计或者说你的程序员设计的表，真的很烂，对很烂，我只能有这个不文雅的词汇来表达 2 这样的表将会给你的系统的性能带来很多问题。

这里直接给出结论，宽表对于POSTGRESQL 他不是一件好事，这里指的宽表是字段类型在 BIGINT INT SMALLINT FLOAT MONEY 等固定字段类型的字段太多引起的你的一列已经要占用一个页面的状态。

当然如果你确认了，你也对这样的设计没有办法，或者你根本就是只是一个

数据库系统的维护者，这里不能将你成为DBA，因为你没有达到这个水平，正确的DBA 运行的姿势一定是要嵌入到业务的运营和表设计当中，至少你要

审核他们。但如果你审核了他们，这样的事情是不应该发生的，所以在发生这样的问题后，开发人员的无知和数据库运行维护人员都对此具有责任。

解决问题的方案也有多重多样，当然你可以在数据库安装的时候，就预估到这届开发人员根本不行，(让梅姨好好审视一下这些开发)， 你可以在安装数据库的时候，加入一个狠活 --with-blocksize=16 ，你的限制会在扩充一倍，当然DBA也会付出其他的代价，自己体会。

这些宽表在查询的时候会严重的导致你的查询效率变低，尤其是哪些字段里就几个有用的情况下，那么你的系统的查询效率一定不高，同时你在UPDATE的时候，效率也会是很差的，整体的数据库系统的性能都会让这样的宽表将系统性能拉低到“马里亚纳海沟”。 具体可以想想 full_page，应对这样的页面频繁的更新的场景。

所以在看到有些系统中有宽表的潜质的情况下，立即要介入，并且停止这样蹩脚的开发的工作方式，他们的脑子里面只有累加，没有分类和优化，你想都不要想。

2 CPU 核心数和POSTGRESQL 系统的稳定性和性能之间的关系

有些单位对于POSTGRESQL 的CPU 核心数，是一种接近变态的“省”的策略。要知道POSTGRESQL 在运行的过程中，是需要针对所有的表进行相关的autovacuum的操作，只要发现了触发点，那么 autovacuum 实际上尽快在一个周期内完成是一件好事，而每一个 autovacuum 完成工作的前提是一个CPU能在这个周期属于他，或者属于他正在工作的autovacuum ，在一个大型系统中的表的数量不会太少，400- 500张表仅仅是一个起步，2000 -3000张表可能是一个常态，一个系统里面 20多张频繁操作的大表，如果你仅仅给这一个系统配备了 4核心的CPU 或 6 核心的CPU 对于这样的系统的运行和维护是有害的。

实际上你要根据你的系统的大表的数量来去预估你CPU的核心数，基本上一个POSTGRESQL 系统的autovacuum 的max _work 数量不要低于6个，你的CPU 的数量不要低于8个，更多的CPU 会让你的POSTGRESQL 在查询时提供更好的并行特性，以及在运行AUTOVACUUM 的时候不会因为你的 “抠门”，导致 “蹩宝” 的行为，最终导致一个表多次无法进入autovacuum的状态，而在最终轮上后，給你放一个大招，导致的IO 在工作期间很高的情况，频繁的发生，或突发性的发生给你的系统运行的稳定性产生不可描述的问题。

3 操作系统的版本

PostgreSQL 是支持多种操作系统的，但这不是说POSTGRESQL 在每种操作系统上，使用同样的硬件配置的情况下，性能的表现是一致，基于主流的POSTGRESQL 的使用和安装等方式，LINUX 上的POSTGRESQL 上的性能要优于其他版本上的POSTGRESQL 的性能，同时更高版本的LINUX 系统为POSTGRESQL 提供更多的基于系统级别的新的性能提高的可能性，如更好的压缩方式，更好的内存访问的方式，更稳定的CPU调用方式，支持更新的CPU架构等等，所以不要认为CENTOS 6 和 CENTOS 8 上的 POSTGRESQL 14 版本的性能是一致的，一定是有差异的。

4 更多的IDEL 连接必须被复用

POSTGRESQL 对于max_connections 的设置虽然没有限制，但是针对POSTGRESQL 在高并发中更多的连接数与性能下降在众多的关于POSTGRESQL 的技术文字中都有记录，众所周知，这与POSTGRESQL 本身的架构设计有关，所以更有效的利用 idel 连接，而不是盲目的去开新的连接是一个优化POSTGRESQL 的好的方法，同时基于POSTGRESQL 进程的使用方式，以及MVCC 的原理，定期的. 通过 htop 或者pg_top 等都可以对POSTGRESQL 正在工作的进程的内存进行显示，当发现 idel 连接的实际驻留的物理内存过多，就需要对这些连接进行清理了。