【乾貨總結】:多是史上最全的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的對比材料

小結