PGSQL性能优化
pgsql优化一般考虑2个指标，一个是响应时间，一个是吞吐量
pgsql的性能优化涉及到多个层面，有硬件，有操作系统，有文件系统
我们首先从硬件开始分析，主要分析CPU，内存，存储
一、CUP有不同的体系结构，其性能是不一样的。
1.SMP/UMA:多CPU对称工作，无主次之分，共享内存。性能好，贵。缺点：CPU数量受限制，过多CUP会造成访问内存冲突。
2.NUMA：多CPU模块，各CPU独立享有自己的内存，也可以访问其他CPU的内存，但是速度慢。典型代表X86系列
MPP：多个SMP联网组成
具体可以参考 https://www.cnblogs.com/yubo/archive/2010/04/23/1718810.html
二、内存有不同的种类，主要有以下类型
SRAM：静态随机存储器。速度快，造价高，不能大规模使用，一般用于CPU 缓存。
SDRAM：同步动态随机存储器。工作时需要同步时钟。
DDR：双倍数据传输速率的SDRAM，DDR是Double Data Rate 缩写。目前主流为DDR4.
服务器内存可以参考https://www.idcbest.com/servernews/11002265.html
三、硬盘有不同的接口，不同的接口性能也不一样。常见的以下三种
1.ATA系列，包括比较老的硬盘接口，例如，IDE（ Integrated Driver Electronics） SATA 2.0， 带宽3Gb/s ，传输速度300MB/s， 数据线最大长度1.5米
2.SCSI系列“Small Computer System Interface”（小型计算机系统接口），Ultra320 SCSI 传输速率320MB。更稳定，更可靠。
3.FC接口：光纤接口的硬盘。带宽4Gb，8Gb
另外硬盘还分不同的存储介质
HDD：普通机械硬盘。SSD：固态硬盘 读写速度相差数倍。
然后，我们从操作系统-文件系统进行分析; EXT2,EXT3,EXT4，XFS
EXT4,
EXT4是Linux系统下的日志文件系统，是EXT3文件系统的后继版本。
（1）Ext4的文件系统容量达到1EB，而文件容量则达到16TB
（2）理论上支持无限数量的子目录
（3）Ext4文件系统使用64位空间记录块数量和i-节点数量
（4）Ext4的多块分配器支持一次调用分配多个数据块
XFS
1）根据所记录的日志在很短的时间内迅速恢复磁盘文件内容
（2）采用优化算法，日志记录对整体文件操作影响非常小
（3） 是一个全64-bit的文件系统，它可以支持上百万T字节的存储空间
（4）能以接近裸设备I/O的性能存储数据
XFS比EXt3有3-30%的性能提升，一般建议Postgresql部署到XFS文件系统上。
IO调优：
1.打开noatime。
每个文件都有ctime，mtime，atime 。pgsql通常不使用这三个属性。尤其是atime可以禁用。
2.调整预读
检查预读设置大小，blockdev --getra /dev/sda (根据自己系统修改)
返回值8192，表示预读这么多个扇区，每个扇区512字节，即0.5M. 所以这里8192表示4M预读。
一般采取默认即可，如果返回是256，可用增大此值。
接着从数据库配置进行分析
1内存配置优化
shared_buffers:共享缓冲区的大小。根据物理可用内存调整，推荐物理内存的四分之一，不超过总内存的二分之一。
work_mem:为每个进程单独分配的内存，主要用于排序，hash操作。如果业务中排序操作比较多，可用增加此项值。
maintenance_work_mem:也是为每个进程单独分配的内存，但主要用于维护操作，如vacuum，create index。
huge_pages:巨型页面的使用会导致更小的页面表以及花费在内存管理上的 CPU 时间更少，从而提高性能。
2预写日志优化
对数据文件进行修改时，先把这些操作写到日志中，数据库文件修改后的脏页不必马上刷新到磁盘中，如果出现了崩溃，可用重做记录在日志中的操作，从而恢复数据库。
一些WAL相关的参数会影响到数据库性能。
检查点发生的频率
checkpoint_timeout : 按照指定的时间间隔生成检查点。合理的范围在 30 秒到 1 天之间。默认是 5 分钟（5min）
checkpoint_completion_target：为了避免检查点产生太多的IO操作，导致系统性能出现大的抖动，可以让Postgresql在平时尽快平均的把脏页刷新到磁盘中，而不必等到检查点时，才发现需要写太多的脏页，这个机制有参数checkpoint_completion_target来控制，默认值为0.5. 也就是在两个检查点间隔的0.5倍时间内完成所有脏页的刷新。
从数据库设计分析
索引
聚簇原理：
聚簇是指：如果一组表有一些共同的列，则将这样一组表存储在相同的数据库块中;聚簇还表示把相关的数据存储在同一个块上。利用聚簇，一个块可能包含多个表的数据。概念上就是如果两个或多个表经常做链接操作，那么可以把需要的数据预先存储在一起。聚簇还可以用于单个表，可以按某个列将数据分组存储。 更加简单的说，比如说，EMP表和DEPT表，这两个表存储在不同的segment中，甚至有可能存储在不同的TABLESPACE中，因此，他们的数据一定不会在同一个BLOCK里。而我们有会经常对这两个表做关联查询，比如说：select * from emp,dept where emp.deptno = dept.deptno .仔细想想，查询主要是对BLOCK的操作，查询的BLOCK越多，系统IO就消耗越大。如果我把这两个表的数据聚集在少量的BLOCK里，查询效率一定会提高不少。
PostgreSQL支持基本的表划分
划分指的是将逻辑上的一个大表分成一些小的物理上的片。划分有很多益处
在某些情况下查询性能能够显著提升，特别是当那些访问压力大的行在一个分区或者少数几个分区时。划分可以取代索引的主导列、减小索引尺寸以及使索引中访问压力大的部分更有可能被放在内存中。
查询或更新访问一个分区的大部分行时，可以通过该分区上的一个顺序扫描来取代分散到整个表上的索引和随机访问，这样可以改善性能。
如果批量操作的需求是在分区设计时就规划好的，则批量装载和删除可以通过增加或者去除分区来完成。执行ALTER TABLE DETACH PARTITION或者使用DROP TABLE删除一个分区远快于批量操作。这些命令也完全避免了批量DELETE导致的VACUUM开销。
很少使用的数据可以被迁移到便宜且较慢的存储介质上。
当一个表非常大时，划分所带来的好处是非常值得的。一个表何种情况下会从划分获益取决于应用，一个经验法则是当表的尺寸超过了数据库服务器物理内存时，划分会为表带来好处
PostgreSQL对下列分区形式提供了内建支持：
范围划分
表被根据一个关键列或一组列划分为“范围”，不同的分区的范围之间没有重叠。例如，我们可以根据日期范围划分，或者根据特定业务对象的标识符划分。
列表划分
通过显式地列出每一个分区中出现的键值来划分表
哈希分区
通过为每个分区指定模数和余数来对表进行分区。每个分区所持有的行都满足：分区键的值除以为其指定的模数将产生为其指定的余数。