PG是什么？
它是一个“学院派”出生，强调标准合规和拓展性的OLTP数据库，通过拓展机制，支持的功能包括GIS、时序、向量、JSON甚至OLAP。
和MySQL的差异
1. 架构模型
MySQL是单进程多线程模型，每一个连接都是一个线程。 PG是多进程，每个连接fork一个独立进程。 模型差异带来的实际影响：
- PG的连接成本比MySQL高，每个连接大概5-10MB
- PG生产环境必须上连接池
- 进程隔离让一个连接的崩溃不会拖垮整个进程
2. MVCC的实现
MySQL InnoDB的MVCC依靠的是undo log机制：旧版本数据放在undo log中，主表中放的是最新版本。 PG的MVCC是多版本并存于堆表：UPDATE实际是插入新行+标记旧行已删除，新旧版本都在表里，靠事务ID判断可见性。 带来的后果：
- VACUUM是PG运维的核心概念，因为旧的数据不会消失，会有“表膨胀”问题，所以需要定期清理旧数据。
- 没有undo log意味着回滚极快，代价是查询需要做可见性判断。
- 事务ID回卷。PG的事务ID是32位，很快就会回卷，必须靠VACUUM定时“冻结”旧数据。
3. 索引：MySQL是聚簇索引，PG是堆表
MySQL InnoDB的主键就是聚簇索引，数据在磁盘中按照主键的物理顺序排序，二级索引存放的是主键（所以存在回表）。 PG所有索引都是“二级索引”，数据在堆表中无序，索引存的物理位置（ctid），这意味着：
- 不存在“主键查询比二级索引查询快”这个说法
- PG支持丰富的索引类型：B-Tree、Hash、GiST等
- PG有覆盖索引语法
include来减少回表
4. 数据标准合规度
- 严格的类型系统，不会默默把字符串转数字
- 窗口函数、子查询等功能支持完善
5. 数据类型支持丰富
PG支持的数据类型，MySQL要么没有，要么就是字符串模拟：
- 数组类型
int[] JSONBint4rabge
6. 复制和高可用
MySQL的主从基于binlog，PG的物理复制基于WAL