MySQL和PGSQL对⽐
MySQL和PGSQL对⽐
⽐较版本：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，链接：
blog.csdn/qq_23435961/article/details/106721851
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特性⽀持情况的对⽐，可以参考： www.sql-workbench/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，部
分索引，表达式索引）
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操作都不需要借助第三⽅⼯具
MySQL 由于⼤部分DDL操作都会锁表，例如加字段、可变长字段类型长度改⼤，所以需要借助percona-toolkit⾥⾯的pt-online-schema-change⼯具去完成操作
将影响减少到最低，特别是对⼤表进⾏DDL操作
25. ⼤版本发布速度
PGSQL PGSQL每年⼀个⼤版本发布，⼤版本发布的第⼆年就可以上⽣产环境，版本迭代速度很快 PGSQL 10正式版推出时间：2017年PGSQL 11正式版推出时间：2018年
PGSQL 12正式版推出时间：2019年
MySQL MySQL的⼤版本发布⼀般是2年~3年，⼀般⼤版本发布后的第⼆年才可以上⽣产环境，避免有坑，版本发布速度⽐较慢
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. 分布式演进mysql社区版国内镜像下载
PGSQL HTAP数据库：cockroachDB、腾讯Tbase 分⽚集： Postgres-XC、Postgres-XL
MySQL HTAP数据库：TiDB 分⽚集： 各种各样的中间件，不⼀⼀列举
⼩结
上⾯的对⽐表还不是很完善，只有⼀些本⼈认为⽐较关键的特性拿出来对⽐
总的来说，MySQL因为需要⽀持更换存储引擎，所以某些功能都要受制于存储引擎层，例如：物理复制
⽽PGSQL不⽀持更换存储引擎（在PGSQL V12开始也⽀持可插拨的表存取接⼝），⽽且⼀直由官⽅统⼀开发和维护，所以相对⽐较稳定，功能也⽐较完善，对得上它的称号：《世界上功能最为强⼤的开源数据库》
PGSQL V12 ⽀持可插拨的表存取接⼝之后，有可能由第三⽅存储引擎来改进PGSQL本⾝的MVCC实现机制，⽽不需要等待官⽅去解决，聚集索引、undo表空间这些都不再是问题

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。