【干货总结】:多是史上最全的MySQL和PGSQL对比材料

运维了MySQL和PGSQL已经有一段时间了，最近接到一个数据库选型需求，因而便开始收集资料整理了一下，而后就有了下面的对比表html

关键词：PostgreSQL 十一、MySQL5.7mysql

比较版本：PostgreSQL 11 VS MySQL5.7（innodb引擎） Oracle官方社区版

版权状况：PostgreSQL 11（免费开源）、MySQL5.7 Oracle官方社区版（免费开源）

1. CPU限制

PGSQL

没有CPU核心数限制，有多少CPU核就用多少

MySQL

能用128核CPU，超过128核用不上

2. 配置文件参数web

PGSQL

一共有255个参数，用到的大概是80个，参数比较稳定，用上个大版本配置文件也能够启动当前大版本数据库

MySQL

一共有707个参数，用到的大概是180个，参数不断增长，就算小版本也会增长参数，大版本之间会有部分参数不兼容状况

3. 第三方工具依赖状况

PGSQL

只有高可用集群须要依靠第三方中间件，例如：patroni+etcd、repmgr

MySQL

大部分操做都要依靠percona公司的第三方工具（percona-toolkit，XtraBackup），工具命令太多，学习成本高，高可用集群也须要第三方中间件，官方MGR集群还没成熟

4. 高可用主从复制底层原理算法

PGSQL

物理流复制，属于物理复制，跟SQL Server镜像/AlwaysOn同样，严格一致，没有任何可能致使不一致，性能和可靠性上，物理复制完胜逻辑复制，维护简单

MySQL

主从复制，属于逻辑复制，（sql_log_bin、binlog_format等参数设置不正确都会致使主从不一致）
大事务并行复制效率低，对于重要业务，须要依赖 percona-toolkit的pt-table-checksum和pt-table-sync工具按期比较和修复主从一致
主从复制出错严重时候须要重搭主从
MySQL的逻辑复制并不阻止两个不一致的数据库创建复制关系

5. 从库只读状态sql

PGSQL

系统自动设置从库默认只读，不须要人工介入，维护简单

MySQL

从库须要手动设置参数super_read_only=on，让从库设置为只读，super_read_only参数有bug，连接： https://baijiahao.baidu.com/s?id=1636644783594388753&wfr=spider&for=pc

6. 版本分支数据库

PGSQL

只有社区版，没有其余任何分支版本，PGSQL官方统一开发，统一维护，社区版有全部功能，不像SQL Server和MySQL有标准版、企业版、经典版、社区版、开发版、web版之分
国内外还有一些基于PGSQL作二次开发的数据库厂商，例如：Enterprise DB、瀚高数据库等等，固然这些只是二次开发并不算独立分支

MySQL

因为历史缘由，分裂为三个分支版本，MariaDB分支、Percona分支、Oracle官方分支，发展到目前为止各个分支基本互相不兼容
Oracle官方分支还有版本之分，分为标准版、企业版、经典版、社区版

7. SQL特性支持数组

PGSQL

SQL特性支持状况支持94种，SQL语法支持最完善，例如：支持公用表表达式（WITH查询）

MySQL

SQL特性支持状况支持36种，SQL语法支持比较弱，例如：不支持公用表表达式（WITH查询）

关于SQL特性支持状况的对比，能够参考： http://www.sql-workbench.net/dbms_comparison.html

8. 主从复制安全性安全

PGSQL
同步流复制、强同步（remote apply)、高安全，不会丢数据
PGSQL同步流复制：全部从库宕机，主库会罢工，主库没法自动切换为异步流复制（异步模式），须要经过增长从库数量来解决，通常生产环境至少有两个从库
手动解决：在PG主库修改参数synchronous_standby_names =''，并执行命令： pgctl reload ，把主库切换为异步模式

主从数据彻底一致是高可用切换的第一前提，因此PGSQL选择主库罢工也是能够理解

MySQL
加强半同步复制，mysql5.7版本加强半同步才能保证主从复制时候不丢数据
mysql5.7半同步复制相关参数：
参数rpl_semi_sync_master_wait_for_slave_count 等待至少多少个从库接收到binlog，主库才提交事务，通常设置为1，性能最高
参数rpl_semi_sync_master_timeout 等待多少毫秒，从库无回应自动切换为异步模式，通常设置为无限大，不让主库自动切换为异步模式
全部从库宕机，主库会罢工，由于没法收到任何从库的应答包

手动解决：在MySQL主库修改参数rpl_semi_sync_master_wait_for_slave_count=0

9. 多字段统计信息markdown

PGSQL

支持多字段统计信息

MySQL

不支持多字段统计信息

10. 索引类型session

PGSQL

多种索引类型（btree , hash , gin , gist , sp-gist , brin , bloom , rum , zombodb , bitmap，部分索引，表达式索引）

MySQL

btree 索引，全文索引（低效），表达式索引(须要建虚拟列)，hash 索引只在内存表

11. 物理表链接算法

PGSQL

支持 nested-loop join 、hash join 、merge join

MySQL

只支持 nested-loop join

12. 子查询和视图性能

PGSQL

子查询，视图优化，性能比较高

MySQL

视图谓词条件下推限制多，子查询上拉限制多

13. 执行计划即时编译

PGSQL

支持 JIT 执行计划即时编译，使用LLVM编译器

MySQL

不支持执行计划即时编译

14. 并行查询

PGSQL

并行查询（多种并行查询优化方法），并行查询通常多见于商业数据库，是重量级功能

MySQL

有限，只支持主键并行查询

15. 物化视图

PGSQL

支持物化视图

MySQL

不支持物化视图

16. 插件功能

PGSQL

支持插件功能，能够丰富PGSQL的功能，GIS地理插件，时序数据库插件，向量化执行插件等等

MySQL

不支持插件功能

17. check约束

PGSQL

支持check约束

MySQL

不支持check约束，能够写check约束，但存储引擎会忽略它的做用，所以check约束并不起做用（mariadb 支持）

18. gpu 加速SQL

PGSQL

可使用gpu 加速SQL的执行速度

MySQL

不支持gpu 加速SQL 的执行速度

19. 数据类型

PGSQL

数据类型丰富，如 ltree，hstore，数组类型，ip类型，text类型，有了text类型再也不须要varchar，text类型字段最大存储1GB

MySQL

数据类型不够丰富

20. 跨库查询

PGSQL

不支持跨库查询，这个跟Oracle 12C之前同样

MySQL

能够跨库查询

21. 备份还原

PGSQL

备份还原很是简单，时点还原操做比SQL Server还要简单，完整备份+wal归档备份（增量）
假若有一个三节点的PGSQL主从集群，能够随便在其中一个节点作完整备份和wal归档备份

MySQL

备份还原相对不太简单，完整备份+binlog备份（增量）
完整备份须要percona的XtraBackup工具作物理备份，MySQL自己不支持物理备份
时点还原操做步骤繁琐复杂

22. 性能视图

PGSQL

须要安装pg_stat_statements插件，pg_stat_statements插件提供了丰富的性能视图：如：等待事件，系通通计信息等
很差的地方是，安装插件须要重启数据库，而且须要收集性能信息的数据库须要执行一个命令：create extension pg_stat_statements命令
不然不会收集任何性能信息，比较麻烦

MySQL

自带PS库，默认不少功能没有打开，并且打开PS库的性能视图功能对性能有影响（如：内存占用致使OOM bug）

23. 安装方式

PGSQL

有各个平台的包rpm包，deb包等等，相比MySQL缺乏了二进制包，通常用源码编译安装，安装时间会长一些，执行命令多一些

MySQL

有各个平台的包rpm包，deb包等等，源码编译安装、二进制包安装，通常用二进制包安装，方便快捷

24. DDL操做

PGSQL

加字段、可变长字段类型长度改大不会锁表，全部的DDL操做都不须要借助第三方工具，而且跟商业数据库同样，DDL操做能够回滚，保证事务一致性

MySQL

因为大部分DDL操做都会锁表，例如加字段、可变长字段类型长度改大，因此须要借助percona-toolkit里面的pt-online-schema-change工具去完成操做
将影响减小到最低，特别是对大表进行DDL操做
DDL操做不能回滚

25. 大版本发布速度

PGSQL

PGSQL每一年一个大版本发布，大版本发布的第二年就能够上生产环境，版本迭代速度很快

PGSQL 9.6正式版推出时间：2016年

PGSQL 10 正式版推出时间：2017年
PGSQL 11 正式版推出时间：2018年
PGSQL 12 正式版推出时间：2019年

MySQL
MySQL的大版本发布通常是2年~3年，通常大版本发布后的第二年才能够上生产环境，避免有坑，版本发布速度比较慢
MySQL5.5正式版推出时间：2010年
MySQL5.6正式版推出时间：2013年
MySQL5.7正式版推出时间：2015年
MySQL8.0正式版推出时间：2018年

26. returning语法

PGSQL

支持returning语法，returning clause 支持 DML 返回 Resultset，减小一次 Client <-> DB Server 交互

MySQL

不支持returning语法

27. 内部架构

PGSQL

多进程架构，并发链接数不能太多，跟Oracle同样，既然跟Oracle同样，那么不少优化方法也是相通的，例如：开启大页内存

MySQL

多线程架构，虽然多线程架构，可是官方有限制链接数，缘由是系统的并发度是有限的，线程数太多，反而系统的处理能力降低，随着链接数上升，反而性能降低
通常同时只能处理200 ~300个数据库链接

28. 汇集索引

PGSQL

不支持汇集索引，PGSQL自己的MVCC的实现机制所致使

MySQL

支持汇集索引

29. 空闲事务终结功能

PGSQL

经过设置 idle_in_transaction_session_timeout 参数来终止空闲事务，好比：应用代码中忘记关闭已开启的事务，PGSQL会自动查杀这种类型的会话事务

MySQL

不支持终止空闲事务功能

30. 应付超大数据量

PGSQL

不能应付超大数据量，因为PGSQL自己的MVCC设计问题，须要垃圾回收，只能期待后面的大版本作优化

MySQL

不能应付超大数据量，MySQL自身架构的问题

31. 分布式演进

PGSQL

HTAP数据库：cockroachDB、腾讯Tbase

分片集群： Postgres-XC、Postgres-XL

MySQL
HTAP数据库：TiDB
分片集群：各类各样的中间件，不一一列举

32. 数据库的文件名和命名规律

PGSQL

PGSQL在这方面作的比较很差，DBA不能在操做系统层面（停库状态下）看清楚数据库的文件名和命名规律，文件的数量，文件的大小

一旦操做系统发生文件丢失或硬盘损坏，很是不利于恢复，由于连名字都不知道

PGSQL表数据物理文件的命名/存放规律是：在一个表空间下面，若是没有建表空间默认在默认表空间也就是base文件夹下，例如：/data/base/16454/3599

base：默认表空间pg_default所在的物理文件夹
16454：表所在数据库的oid
3599：就是表对象的oid，固然，一个表的大小超出1GB以后会再生成多个物理文件，还有表的fsm文件和vm文件，因此一个大表实际会有多个物理文件

因为PGSQL的数据文件布局内容太多，你们能够查阅相关资料

固然这也不能全怪PGSQL，做为一个DBA，时刻作好数据库备份和容灾才是正道，作介质恢复通常是万不得已的状况下才会作

MySQL

数据库名就是文件夹名，数据库文件夹下就是表数据文件，每一个表都有对应的frm文件和ibd文件，存储元数据和表/索引数据，清晰明了，作介质恢复或者表空间传输都很方便

33. 权限设计

PGSQL

PGSQL在权限设计这块是比较坑爹，抛开实例权限和表空间权限，PGSQL的权限层次有点像SQL Server，db=》schema=》object

要说权限，这里要说一下Oracle，用Oracle来类比

在ORACLE 12C以前，实例与数据库是一对一，也就是说一个实例只能有一个数据库，不像MySQL和SQL Server一个实例能够有多个数据库，而且能够随意跨库查询

而PGSQL不能跨库查询的缘由也是这样，PGSQL容许建多个数据库，跟ORACLE类比就是有多个实例（以前说的实例与数据库是一对一）

一个数据库至关于一个实例，由于PGSQL容许有多个实例，因此PGSQL单实例不叫一个实例，叫集簇（cluster），集簇这个概念能够查阅PGSQL的相关资料

PGSQL里面一个实例/数据库下面的schema至关于数据库，因此这个schema的概念对应MySQL的database

注意点：正由于是一个数据库至关于一个实例，PGSQL容许有多个实例/数据库，因此数据库之间是互相逻辑隔离的，致使的问题是，不能一次对一个PGSQL集簇下面的全部数据库作操做

必需要逐个逐个数据库去操做，例如上面说到的安装pg_stat_statements插件，若是您须要在PGSQL集簇下面的全部数据库都作性能收集的话，须要逐个数据库去执行加载命令

又例如跨库查询须要dblink插件或fdw插件，两个数据库之间作查询至关于两个实例之间作查询，已经跨越了实例了，因此须要dblink插件或fdw插件，因此道理很是简单

权限操做也是同样逐个数据库去操做，还有一个就是PGSQL虽然像SQL Server的权限层次结构db=》schema=》object，可是实际会比SQL Server要复杂一些，还有就是新建的表还要另外受权

在PGSQL里面，角色和用户是同样的，对新手用户来讲有时候会傻傻分不清，也不知道怎么去用角色，因此PGSQL在权限设计这一块确实比较坑爹

MySQL

使用mysql库下面的5个权限表去作权限映射，简单清晰，惟一问题是缺乏权限角色

user表
db表
host表
tables_priv表
columns_priv表

34. 发展历史

PGSQL
在1995年，开发人员Andrew Yu和Jolly Chen在Postgres中添加了一个SQL（Structured Query Language，结构化查询语言）翻译程序，该版本叫作Postgres95，在开放源代码社区发放。
在1996年，再次对Postgres95作了较大的改动，并将其命名为PostgresSQL 6.0版发布，PostgresSQL 的名字就此定型，从1995年算起，大概有24年历史

MySQL
在1996年，MySQL 1.0发布，它只面向一小拨人，至关于内部发布。
到了1996年10月，MySQL 3.11.1发布(MySQL没有2.x版本)，最开始只提供Solaris操做系统下的二进制版本，一个月后，Linux版本出现
从1996年算起，大概有23年历史

小结

上面的对比表还不是很完善，只有一些本人认为比较关键的特性拿出来对比

总的来讲，两种数据库都有优缺点，你们在选型的时候须要谨慎选择，MySQL须要多折腾，PGSQL让你少折腾，由于PGSQL自己已经作的比较完善，不太须要依赖一些第三方工具

固然，若是在MySQL上选择Percona 分支，MariaDB分支，或者Oracle官方的MySQL企业版就另当别论

MySQL由于须要支持更换存储引擎，因此某些功能都要受制于存储引擎层，例如：物理复制

而PGSQL不支持更换存储引擎（在PGSQL V12开始也支持可插拨的表存取接口），并且一直由官方统一开发和维护，因此相对比较稳定，功能也比较完善，对得上它的称号：《世界上功能最为强大的开源数据库》

PGSQL V12 支持可插拨的表存取接口以后，有可能由第三方存储引擎来改进PGSQL自己的MVCC实现机制，而不须要等待官方去解决，汇集索引、undo表空间这些都再也不是问题

若是业务复杂的话，其实PGSQL是最佳选择，分享一篇文章：为何“去O”惟有PG

若有不对的地方，欢迎你们拍砖o(∩_∩)o

本文版权归做者全部，未经做者赞成不得转载。

【干货总结】:多是史上最全的MySQL和PGSQL对比材料

【干货总结】:多是史上最全的MySQL和PGSQL的对比材料

小结