【乾貨總結】:可能是史上最全的MySQL和PGSQL的對比材料
運維了MySQL和PGSQL已經有一段時間了,最近接到一個數據庫選型需求,於是便開始收集資料整理了一下,然後就有了下面的對比表
關鍵詞:PostgreSQL 11、MySQL5.7
比較版本:PostgreSQL 11 VS MySQL5.7(innodb引擎) Oracle官方社區版
1. CPU限制
2. 配置文件參數
3. 第三方工具依賴情況
4. 底層主從複製原理
大事務並行複製效率低,對於重要業務,需要依賴 percona-toolkit的pt-table-checksum和pt-table-sync工具定期比較和修復主從一致
主從複製出錯嚴重時候需要重搭主從
MySQL的邏輯複製並不阻止兩個不一致的數據庫建立複製關係
5. 從庫只讀狀態
6. 版本分支
國內外還有一些基於PGSQL做二次開發的數據庫廠商,例如:Enterprise DB、瀚高數據庫等等,當然這些只是二次開發並不算獨立分支
Oracle官方分支還有版本之分,分爲標準版、企業版、經典版、社區版
7. SQL特性支持
8. 主從複製安全性
同步流複製、強同步(remote apply)、高安全,不會丟數據
PGSQL同步流複製:所有從庫宕機,主庫會罷工,主庫無法自動切換爲異步流複製(異步模式),需要通過增加從庫數量來解決,一般生產環境至少有兩個從庫
手動解決:在PG主庫修改參數synchronous_standby_names ='',並執行命令: pgctl reload ,把主庫切換爲異步模式
增強半同步複製 ,mysql5.7版本增強半同步才能保證主從複製時候不丟數據
mysql5.7半同步複製相關參數:
參數rpl_semi_sync_master_wait_for_slave_count 等待至少多少個從庫接收到binlog,主庫才提交事務,一般設置爲1,性能最高
參數rpl_semi_sync_master_timeout 等待多少毫秒,從庫無迴應自動切換爲異步模式,一般設置爲無限大,不讓主庫自動切換爲異步模式
所有從庫宕機,主庫會罷工,因爲無法收到任何從庫的應答包
9. 多字段統計信息
10. 索引類型
11. 物理表連接算法
12. 子查詢和視圖性能
13. 執行計劃即時編譯
14. 並行查詢
有限,只支持主鍵並行查詢
15. 物化視圖
不支持物化視圖
16. 插件功能
不支持插件功能
17. check約束
不支持check約束,可以寫check約束,但存儲引擎會忽略它的作用,因此check約束並不起作用(mariadb 支持)
18. gpu 加速SQL
不支持gpu 加速SQL 的執行速度
19. 數據類型
數據類型不夠豐富
20. 跨庫查詢
可以跨庫查詢
21. 備份還原
假如有一個三節點的PGSQL主從集羣,可以隨便在其中一個節點做完整備份和wal歸檔備份
備份還原相對不太簡單,完整備份+binlog備份(增量)
完整備份需要percona的XtraBackup工具做物理備份,MySQL本身不支持物理備份
時點還原操作步驟繁瑣複雜
22. 性能視圖
不好的地方是,安裝插件需要重啓數據庫,並且需要收集性能信息的數據庫需要執行一個命令:create extension pg_stat_statements命令
否則不會收集任何性能信息,比較麻煩
自帶PS庫,默認很多功能沒有打開,而且打開PS庫的性能視圖功能對性能有影響(如:內存佔用導致OOM bug)
23. 安裝方式
有各個平臺的包rpm包,deb包等等,源碼編譯安裝、二進制包安裝,一般用二進制包安裝,方便快捷
24. DDL操作
將影響減少到最低,特別是對大表進行DDL操作
DDL操作不能回滾
25. 大版本發佈速度
PGSQL 11 正式版推出時間:2018年
PGSQL 12 正式版推出時間:2019年
MySQL
MySQL的大版本發佈一般是2年~3年,一般大版本發佈後的第二年纔可以上生產環境,避免有坑,版本發佈速度比較慢
MySQL5.5正式版推出時間:2010年
MySQL5.6正式版推出時間:2013年
MySQL5.7正式版推出時間:2015年
MySQL8.0正式版推出時間:2018年
26. returning語法
27. 內部架構
多線程架構,雖然多線程架構,但是官方有限制連接數,原因是系統的併發度是有限的,線程數太多,反而系統的處理能力下降,隨着連接數上升,反而性能下降
一般同時只能處理200 ~300個數據庫連接
28. 聚集索引
支持聚集索引
29. 空閒事務終結功能
不支持終止空閒事務功能
30. 應付超大數據量
不能應付超大數據量,MySQL自身架構的問題
31. 分佈式演進
HTAP數據庫:TiDB
分片集羣: 各種各樣的中間件,不一一列舉
32. 數據庫的文件名和命名規律
16454:表所在數據庫的oid
3599:就是表對象的oid,當然,一個表的大小超出1GB之後會再生成多個物理文件,還有表的fsm文件和vm文件,所以一個大表實際會有多個物理文件
數據庫名就是文件夾名,數據庫文件夾下就是表數據文件,每個表都有對應的frm文件和ibd文件,存儲元數據和表/索引數據,清晰明瞭,做介質恢復或者表空間傳輸都很方便
33. 權限設計
使用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表空間這些都不再是問題
如有不對的地方,歡迎大家拍磚o(∩_∩)o
本文版權歸作者所有,未經作者同意不得轉載。