postgresql和mysql的区别有哪些

共计 6711 个字符，预计需要花费 17 分钟才能阅读完成。

这篇文章主要为大家展示了“postgresql 和 mysql 的区别有哪些”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“postgresql 和 mysql 的区别有哪些”这篇文章吧。

区别：1、PGSQL 没有 CPU 核心数限制，而 mysql 有限制；2、PGSQL 的配置文件参数一共有 255 个，MySQL 一共有 707 个；3、PGSQL 支持多字段统计信息，而 MySQL 不支持；4、PGSQL 支持执行计划即时编译，MySQL 不支持。

本教程操作环境：windows7 系统、PostgreSQL 11 MySQL5.7 版本、Dell G3 电脑。

PostgreSQL 是一种特性非常齐全的自由软件的对象 - 关系型数据库管理系统（ORDBMS）。

PostgreSQL 支持大部分的 SQL 标准并且提供了很多其他现代特性，如复杂查询、外键、触发器、视图、事务完整性、多版本并发控制等。同样，PostgreSQL 也可以用许多方法扩展，例如通过增加新的数据类型、函数、操作符、聚集函数、索引方法、过程语言等。另外，因为许可证的灵活，任何人都可以以任何目的免费使用、修改和分发 PostgreSQL。

postgresql 和 mysql 的区别对比

比较版本：PostgreSQL 11 VS MySQL5.7（innodb 引擎）Oracle 官方社区版版权情况：PostgreSQL 11（免费开源）、MySQL5.7 Oracle 官方社区版（免费开源）

1. CPU 限制

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

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

2. 配置文件参数

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. 从库只读状态

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 特性支持

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

MySQLSQL 特性支持情况支持 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. 多字段统计信息

PGSQL 支持多字段统计信息

MySQL 不支持多字段统计信息

10. 索引类型

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

MySQLbtree 索引，全文索引（低效），表达式索引 (需要建虚拟列)，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. 大版本发布速度

PGSQLPGSQL 每年一个大版本发布，大版本发布的第二年就可以上生产环境，版本迭代速度很快 PGSQL 9.6 正式版推出时间：2016 年 PGSQL 10 正式版推出时间：2017 年 PGSQL 11 正式版推出时间：2018 年 PGSQL 12 正式版推出时间：2019 年

MySQLMySQL 的大版本发布一般是 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. 分布式演进

PGSQLHTAP 数据库：cockroachDB、腾讯 Tbase 分片集群：Postgres-XC、Postgres-XLMySQLHTAP 数据库：TiDB 分片集群：各种各样的中间件，不一一列举

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

PGSQLPGSQL 在这方面做的比较不好，DBA 不能在操作系统层面（停库状态下）看清楚数据库的文件名和命名规律，文件的数量，文件的大小一旦操作系统发生文件丢失或硬盘损坏，非常不利于恢复，因为连名字都不知道 PGSQL 表数据物理文件的命名 / 存放规律是：在一个表空间下面，如果没有建表空间默认在默认表空间也就是 base 文件夹下，例如：/data/base/16454/3599base：默认表空间 pg_default 所在的物理文件夹 16454：表所在数据库的 oid3599：就是表对象的 oid，当然，一个表的大小超出 1GB 之后会再生成多个物理文件，还有表的 fsm 文件和 vm 文件，所以一个大表实际会有多个物理文件由于 PGSQL 的数据文件布局内容太多，大家可以查阅相关资料当然这也不能全怪 PGSQL，作为一个 DBA，时刻做好数据库备份和容灾才是正道，做介质恢复一般是万不得已的情况下才会做

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

33. 权限设计

PGSQLPGSQL 在权限设计这块是比较坑爹，抛开实例权限和表空间权限，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 年历史

以上是“postgresql 和 mysql 的区别有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！