数据库优化是一个综合工程，不仅仅是需要 D BA 参与，更重要的是研发设计人员针对 P G 数据库的特点来进行相关的优化设计。不过对于 D BA 来说，一旦接到上线和运维任务，基本上都是木已成舟，软件设计方面留下的坑已经挖好， D BA 的作为已经十分有限了。不过既然要干运维，那么少不了就要参与优化。 P G 的优化工作该如何开展呢？今天我从几个主要的方面聊聊 P G 优化的几个常见的角度。针对 P G 数据库，只要做好了下面几个方面的优化工作，那么运维起来也就比较省心了。
l 硬件资源 问题 ：如果数据库服务器硬件资源不足，例如 CPU 、内存、磁盘 IO 等，会导致系统性能下降，响应时间变慢。
l 操作系统配置不合理：如果操作系统没有针对 PG 数据库进行优化，那么 P G 数据库也无法发挥最 佳的效能，因此针对 P G 数据库的优化，从操作系统参数调整入手永远是不会错的。
l 文件系统配置不合理：对于一些负载较高的大型数据库来说，如果无法发挥后端存储的 I O 能力，或者说让后端磁盘出现了性能问题，那么就会严重影响 P G 数据库的性能甚至稳定性。对于大型数据库来说，文件系统设计与配置一定要十分用心。
l S QL 不够优化 ：如果 应用 没有经过优化，可能会导致查询效率低下，索引 设计不合理，缺少必要的索引，过多的单列索引以及索引类型使用不合理等都会带来性能问题。最后 不合理 多表 的 JOIN 、 WHERE 子句 和大表并行扫码都可能成为性能杀手 。
l 数据库结构设计不合理：如果数据库结构设计不合理，可能会导致查询效率低下，例如表过度归一化、 大表未分区或者分区设置不合理，表或者索引的的 F ILL FACTOR 参数设置不合理导致的热块冲突 。 索引设计不合理产生的不必要的写成本过高。应该存储到对象存储中的非结构化数据存储到 P G 数据库中等。表分区设计不合理，时序数据没有使用 t imescaledb 的自动分区与自动压缩特性也会导致时序数据访问的性能不佳。
l 数据库参数设置不合理：如果 PostgreSQL 数据库参数设置不合理，可能会导致数据库性能低下，例如 shared_buffers 、 work_mem 、 W AL /Checkpoint 等参数的设置 等 。
l 并发控制不合理：如果数据库并发控制不合理，可能会导致性能下降 ，这方面包含 事务隔离级别设置不合理 ，并发度相关参数设置不合理等 。
l 缓存命中率低：如果缓存命中率低，会导致频繁的磁盘 IO 操作，从而降低数据库性能。
l 访问冷数据的性能不足： P G 数据库是采用 D OUBLE CACHE 机制的，冷数据是指在 S HARED BUFFERS 和 O S CACHE 中都不存在的数据，这些数据一旦要访问，要产生大量的物理 I O ，访问性能较差。
l 自动化任务冲突：如果数据库中存在大量的自动化任务，例如备份、VACUUM 、定时任务等，可能会导致任务之间的冲突，从而影响系统性能。
硬件资源不足的问题我们就不多加讨论了，这种情况一般会出现在 C PU 、 I O 等方面，在分析这方面问题的时候，需要关注 R 队列的长度是否超过 C PU 逻辑核数的 2 倍以上，对于 I O 来说，不仅仅要看 I OPS/IO 吞吐量等指标，更重要的是要看 I O 延时是否合理。
操作系统配置不合理是绝大多数 P G 数据库都存在的问题，这方面实际上是有一些最 佳实践的。
[sysctl]
vm.swappiness = 1
vm.dirty_background_ratio = 10
vm.dirty_ratio = 40
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500
kernel.shmmax = 18446744073692700000
kernel.shmall = 18446744073692700000
kernel.shmmni = 4096
kernel.sem = 250 512000 100 2048
fs.file-max = 312139770
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 2048 65499
# Permits sockets in the time-wait state to be reused for new connections:
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_budget = 1024
net.core.netdev_max_backlog = 2048
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
kernel.panic_on_oops = 1
# We don't need NUMA balancing in this box:
kernel.numa_balancing = 0
# Used if not defined by the service:
net.core.somaxconn = 4096
# Other parameters to override throughput-performance template
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1
net.netfilter.nf_conntrack_max = 250000
net.ipv4.tcp_max_syn_backlog=4096
[vm]
transparent_hugepages=never
上面是一个红帽公司对于 PG 数据库 RHEL 参数优化的建议，大家可以参考，对于绝大多数高负载的系统来说，都是有效的。大家要注意的是，关于脏块回写的设置，对于不同的写 I O 负载以及不同的底层 I O 硬件，可能调整会有不同，甚至会有截然相反的配置策略。要注意的是，绝对不能因为不合理的脏块刷新策略导致了 O S IO 负载的过载。在此前提下，缩短 I O 写盘的周期对于提高并发负载是有帮助的。
文件系统的设计对于大型系统来说十分关键，很多 DBA 都只会设置一个 $ PGDATA ，整个数据库都放在同一个文件系统上，这需要对文件系统底层的卷做十分细致的优化，确保整个卷的 I O 能力是优秀的，这一点总是无法做到的。因此在数据库设计的时候就通过 W AL 与数据文件分离，热数据与冷数据分离，通过表空间隔离热点 I O 等方式规划 P G 数据库的文件存储。如果应用系统已经无法通过表空间来隔离 I O 热点，那么通过软连接将部分库的目录迁移到其他文件系统也是一个可行的方案。
对于数据库参数来说，实际上不同的应用场景下的最 佳调整方案是不同的，一般来说，设置合理的 s hared_buffers ，以及优化好相关的而 b gwriter ， W AL ， checkpoint，work_mem，V ACUUM 等相关的参数，就能够满足大多数应用的需求了。在这里我们就不做过多的讨论了。在这方面我以前写过十多篇文章，有兴趣的朋友可以到公众号通过搜索 “性能优化”或者通过公众号的菜单去查找。
并发控制不合理方面的问题是比较容易被忽视的问题，事务隔离级别用错对于性能的影响极大，不过一般情况下我们都是使用 r ead committed ，不要轻易去修改数据库级的事务隔离级别。
并发的另外一个方面是系统中的各类并发访问的控制，特别是并行执行的设置。 m ax_worker_processes 、 max_parallel_workers、max_parallel_maintenance_workers和max_parallel_workers_per_gather 等参数对数据库的并发度控制都至关重要 。
如果并发相关的设置过小，那么当活跃会话数量不高的时候，无法充分发挥服务器硬件的资源优势，造成巨大的浪费。 P G 数据库可以支撑巨大的数据库与极高的并发，因此如果服务器的配置足够好，系统资源使用率不高，但是应用性能无法达到设计要求，那么我们就应该关注一下是否并发控制相关的参数设置过低了。默认的 P G 参数里 , max_worker_processes 是偏小的，仅仅是 8,对于有上百甚至上千个逻辑核数的服务器来说是完全不够用的。
当然如果因为并发控制参数设置的过高而导致了 C PU 等资源出现了不足，因为 I OPS 过大或者 I O 吞吐量过大，底层存储能力不足导致的 I O 延时过大等现象，那么适当调低这些参数对数据库的整体性能提升是有帮助的。
P G 的 S HARED_BUFFERS 设置不合理可能会导致缓冲区命中率不高，从而影响 S QL 的执行性能。不过 P G 数据库是使用 D OUBLE BUFFER 机制的，要想为你的应用调整好缓冲区并不容易。再怎么调整都无法满足不同场景的应用，有些时候 D BA 真的很难通过调整来优化这方面的性能。对于一些定期的报表等应用，在跑批之前做数据预热可能是 D BA 能够控制的优化方法，也是最为有效的提升统计报表性能的方法。
最后一点，自动化任务冲突是所有数据库都会遇到的性能问题，如果数据库备份，大批量统计作业与大数据量导入导出同时发生，再好的硬件也可能撑不住，因此在设计这些定期任务的时候，一定要通过算法将这些作业分开，千万不要让这些大型操作存在最大公约数。否则哪怕现在你的系统没问题，几年后，还是会出问题的。
