开始乱说

主要是结合postgres数据库自身特点，根据具体的业务场景，作出相应调整，使其更加合理。

数据库作为一个整体对外提供服务，单是其内部是由不同的功能模块组成，相互协调来共同完成任务。

各个功能模块完成不同的功能，每个模块的特点也不同，在调整的时候至少需要理解各个模块实现的基本原理（属于内功需修炼）才好下手。

各个功能模块又相互影响，共享资源，也就是他们之间会存在竞争资源。比如当系统发生gc时对几乎各个模块都会产生影响。

有些问题可能是多个模块共同产生的。 最常见的如一条慢sql，可能引起的原因可能是索引不合理，执行计划跑偏，sql本身问题，lock, 当时系统正在gc。等等。

数据库作为一个产品，为了适应更广泛的场景，通常情况下默认设置都比较保守。默认的设置能够在大多数情况下满足的的需求，但是在对性能用所要求的生产环境下需必要的调整，甚至会私人定制。

不同场景区别对待

场景主要分为TP、AP两种场景。

不同的使用场景优化的方向应该是不同的，侧重点也会不同。

TP 强调的短平快，注重TPS。相当于跑车追求速度，效率。

AP 强调的吞吐量，相当于大卡车。

针对不同车辆设计不同的道路才合理。

在跑车的赛道上开来一辆大卡车，彼此伤害。TP如果不幸就此挂掉，真的不能说是系统不够健壮。

补充： 慢Sql可视为TP系统性能上的bug , 高速运行的列车，飞机任何碰撞都是致命的。

TP 系统中一条慢Sql的伤害

  • 伤磁盘IO
  • 伤系统CUP
  • 伤系统内存
  • 伤数据库MVCC LOCK VACUUM
  • 伤系统统计信息、temp
  • 伤数据库缓存
  • 伤数据库连接数

监测很重要

你是我的眼 👀

作用

  • 早期发现问题

  • 评估调整后效果

工具

  • 监控系统

  • 日志系统

功能模块概览

  • vacuum

避免在高峰时发生，又能及时处理，避免表膨胀。调整触发条件及手动触发

  • checkpoint

频率，IO平滑度

  • sql

满足功能同时是否考虑性能

  • wal

输出量，FPI

  • hotupdate

热更新比例 调整fillfactor

  • 缓存 buffer

命中率 是否产生tempfile

  • 索引 index

利用率，需要加，没必要的删

  • 锁 lock

锁等待,死锁

  • SQL

使用是否合理

木桶效应

一台应用的整体提供服务的能力同样取决于最短的那块板子，将最短的那块板子性能提升将会提升整个应用的服务能力。

初期通常局部的优化效果优于加一个同样配置的服务器。

具体优化措施

大量写场景

  • 删除 无用的index

索引的维护需要额外的代价

  • 力争 hotupdate

新旧数据在一个page中

  • 调整 fillfactor

增加hotupdate比例

  • 只更新变化的列

降低IO，网络，wal日志的体量

  • 批量更新，一个事务更新多条记录

批操作，减少连接事务开销

  • 锁

事务之间相互等待，相互踩踏

  • where 条件索引利用情况，更新前需要查找具体记录

快速定位目标数据所在的位置

  • 监控表空间膨胀

更新使用了mvcc 技术，利用空间来节省时间。同时带来了空间膨胀。闲时处理

  • checkpoint

降低checkpoint发生频率及剧烈程度。减少FPI

  • 频繁更新业务

频繁更新，指的是同一条记录的更新。比如状态信息。位置信息等。推荐使用其他数据库 如redis

  • 多写

在单节点上的优化做好了再考虑多写

总结的很全面的关于开发人员如何优化数据 https://www.modb.pro/db/26031?xzs=