共計 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 行業資訊頻道！