PostgreSQL 数据库性能

1：数据库性能常用的度量指标

（1）运行时间 run time  

（2）QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

（3）TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

2：数据库性能常见的依赖因素

（1）环境

机器配置、

网络带宽时延、

HA\集群架构（同步、异步复制策略）

数据库参数（postgresql.conf 刷盘策略等）

（2）业务场景

表定义

数据量

SQL

事务隔离级别

并发度

3：数据库运行时间消耗

(1) 客户端：建连\断连， SQL发送、 结果集接受、处理

(2) 数据库服务端: 通信层(采用连接池、用户态网络、逻辑连接)， SQL优化（优化）\执行层（线程池），写日志（并发）、数据刷盘（刷页线程、shared）、结果输出

(3) 网络延迟

4： SQL执行时间分析

SQL--->查询解析（词法分析token keyword、语法分析parsetree、语义分析querytree）---> 查询优化 （查询重写）---> 优化器 （代价估算、生成执行计划 plantree） -------> 绑参 ------> 执行器 ----->存储引擎

5： 逻辑上常见的SQL执行顺序【】

【7】select 【8】distinct 【11】

【1】from

【3】 join

【2】on

【4】where

【5】group by

【6】having

【9】order by

【10】limit

6： 不同执行计划的选择 （explain的使用：PgSQL · 最佳实践 · EXPLAIN 使用浅析）

（1）如何扫描表：

        Seq Scan ：全表顺序扫描， 一般查询没有索引的表需要全表扫描。

        Index Scan： 索引扫描， 主要用来再where条件中存在索引列是的扫描。（建表的时候可以创建索引列）。一般由于Seq Scan。

        Bitmap index Scan：一种索引扫描， 节点每次执行返回的是一个位图而不是一个元组，其中位图中每位代表了一个扫描到的数据块。这样做最大的好处就是把Index Scan 的随机读转换成了按照数据块的物理顺序读取，在数据量比较大的时候，这会大大提升扫描的性能。

         Bitmap heap Scan： 作为BitmapIndex Scan 的父节点， 将BitmapIndex Scan 返回的位图转换为对应的元组。

        如何选择：

        [1]:  大多数情况下，Index Scan 要比 Seq Scan 快。但是如果获取的结果集占所有数据的比重很大时，这时Index Scan 因为要先扫描索引再读表数据反而不如直接全表扫描来的快。

        [2]:  如果获取的结果集的占比比较小，但是元组数很多时，可能Bitmap Index Scan 的性能要比Index Scan 好。

        代价估计信息：

        cost 就是该执行节点的代价估计。它的格式是xxx..xxx，在.. 之前的是预估的启动代价，即找到符合该节点条件的第一个结果预估所需要的代价，在..之后的是预估的总代价。而父节点的启动代价包含子节点的总代价。

        rows 代表预估的行数， 根据表的统计信息预估来；

        width 代表预估的结果宽度，单位字节。根据表的统计信息预估来。

        真实执行信息：

        当EXPLAIN 命令中ANALYZE 选项为on时，会在代价估计信息之后输出真实执行信息，包括：

• actual time 执行时间，格式为xxx..xxx，在.. 之前的是该节点实际的启动时间，即找到符合该节点条件的第一个结果实际需要的时间，在..之后的是该节点实际的执行时间
• rows 指的是该节点实际的返回行数
• loops 指的是该节点实际的重启次数。如果一个计划节点在运行过程中，它的相关参数值（如绑定变量）发生了变化，就需要重新运行这个计划节点。

（2）如何join

        Nested Loop

        Hash

        Merge

  (3) 如何排序

（4）如何处理子查询

（5）其他等价的执行计划

SQL优化器如何选择执行计划

（1）RBO 基于规则的优化器、动态适应性差

（2）CBO 基于代价的优化器、目前关系数据库的主流技术

PG的锁等待问题：

pg_locks  + pg_thread_wait_status + pg_stat_activity

PostgreSQL 锁等待监控 珍藏级SQL - 谁堵塞了谁-阿里云开发者社区

linux 常用的数据库性能分析、问题诊断工具

（1）性能分析： top、htop、iotop、vmstat、sar 、 netstat、perf、iostat

  (2)  问题诊断：gdb、gstack、gcore、lsof、tcpdump 

PG外部GUI管理工具

(1) pgadmin4

(2) DBeaver