PG数据库优化工作应该如何开展.docxVIP

数据库优化是一个综合工程，不仅仅是需要DBA参与，更重要的是研发设计人员针对PG数据库的特点来进行相关的优化设计。不过对于DBA来说，一旦接到上线和运维任务，基本上都是木已成舟，软件设计方面留下的坑已经挖好，DBA的作为已经十分有限了。不过既然要干运维，那么少不了就要参与优化。PG的优化工作该如何开展呢？今天我从几个主要的方面聊聊PG优化的几个常见的角度。针对PG数据库，只要做好了下面几个方面的优化工作，那么运维起来也就比较省心了。

●硬件资源问题：如果数据库服务器硬件资源不足，例如CPU、内存、磁盘IO等，会导致系统性能下降，响应时间变慢。

●操作系统配置不合理：如果操作系统没有针对PG数据库进行优化，那么PG数据库也无法发挥最佳的效能，因此针对PG数据库的优化，从操作系统参数调整入手永远是不会错的。

●文件系统配置不合理：对于一些负载较高的大型数据库来说，如果无法发挥后端存储的IO能力，或者说让后端磁盘出现了性能问题，那么就会严重影响PG数据库的性能甚至稳定性。对于大型数据库来说，文件系统设计与配置一定要十分用心。

●SQL不够优化：如果应用没有经过优化，可能会导致查询效率低下，索引设计不合理，缺少必要的索引，过多的单列索引以及索引类型使用不合理等都会带来性能问题。最后不合理多表的JOIN、WHERE子句和大表并行扫码都可能成为性能杀手。

●数据库结构设计不合理：如果数据库结构设计不合理，可能会导致查询效率低下，例如表过度归一化、大表未分区或者分区设置不合理，表或者索引的的FILLFACTOR参数设置不合理导致的热块冲突。索引设计不合理产生的不必要的写成本过高。应该存储到对象存储中的非结构化数据存储到PG数据库中等。表分区设计不合理，时序数据没有使用timescaledb的自动分区与自动压缩特性也会导致时序数据访问的性能不佳

●数据库参数设置不合理：如果PostgreSQL数据库参数设置不合理，可能会导致数据库性能低下，例如shared_buffers、work_mem、WAL/Checkpoint等参数的设置等。

●并发控制不合理：如果数据库并发控制不合理，可能会导致性能下降，这方面包含事务隔离级别设置不合理，并发度相关参数设置不合理等。

●缓存命中率低：如果缓存命中率低，会导致频繁的磁盘IO操作，从而降低数据库性能。

●访问冷数据的性能不足：PG数据库是采用DOUBLECACHE机制的，冷数据是指在SHAREDBUFFERS和OSCACHE中都不存在的数据，这些数据一旦要访问，要产生大量的物理IO，访问性能较差。

●自动化任务冲突：如果数据库中存在大量的自动化任务，例如备份、VACUUM、定时任务等，可能会导致任务之间的冲突，从而影响系统性能。

硬件资源不足的问题我们就不多加讨论了，这种情况一般会出现在CPU、IO等方面，在分析这方面问题的时候，需要关注R队列的长度是否超过CPU逻辑核数的2倍以上，对于IO来说，不仅仅要看IOPS/IO吞吐量等指标，更重要的是要看IO延时是否合理。

操作系统配置不合理是绝大多数PG数据库都存在的问题，这方面实际上是有一些最佳实践的。

上面是一个红帽公司对于PG数据库RHEL参数优化的建议，大家可以参考，对于绝大多数高负载的系统来说，都是有效的。大家要注意的是，关于脏块回写的设置，对于不同的写IO负载以及不同的底层IO硬件，可能调整会有不同，甚至会有截然相反的配置策略。要注意的是，绝对不能因为不合理的脏块刷新策略导致了OSIO负载的过载。在此前提下，缩短IO写盘的周期对于提高并发负载是有帮助的。

文件系统的设计对于大型系统来说十分关键，除了使用XFS与EXT4等带日志的文件系统并且打开日志功能外，设置文件系统的mount参数对性能也有很大影响。文件系统的条带大小、块大小要与PG数据库匹配，MOUNT时也要加入nobarrier、noatime、nodiratime等参数，并做好扇区对齐，除此之外就是文件存储方面的性能优化了。

很多DBA都只会设置一个$PGDATA，整个数据库都放在同一个文件系统上，这需要对文件系统底层的卷做十分细致的优化，确保整个卷的IO能力是优秀的，这一点总是无法做到的。因此在数据库设计的时候就通过WAL与数据文件分离，热数据与冷数据分离，通过表空间隔离热点IO等方式规划PG数据库的文件存储。如果应用系统已经无法通过表空间来隔离IO热点，那么通过软连接将部分库的目录迁移到其他文件系统也是一个可行的方案。

对于数据库参数来说，实际上不同的应用场景下的最佳调整方案是不同的，一般来说，设置合理的shared_buffers，以及优化好相关的bgwriter，WAL，checkpoint，work_mem，VACUUM等相关的参数，就能够满