Postgres 9.1 與 Mysql 5.6 InnoDB？

Question

一個簡單的問題 - 對於 2012 年要求與 ACID 兼容的中/大型數據庫，什么會更好。

我已經閱讀了有關 mySQL 與 pgSQL 的所有內容（大部分內容），但其中大多數帖子分別與版本 4,5.1 和 7,8 相關，並且已經過時（2008,2009）。 現在快 2012 年了，所以我想我們可以嘗試重新審視這個問題。

基本上我想知道 PostgreSQL 中是否有任何東西比 MySQL 的易用性、可用性和更大的開發人員/知識庫更重要。

MySQL的查詢優化器還傻嗎？ 在非常復雜的查詢上它仍然非常慢嗎？

打我！ :)

PS。 並且不要將我發送到護目鏡或維基。 我正在尋找幾個具體點而不是概述 + 我更信任 StackOverflow，而不是一些“聰明人”閃耀着光芒的隨機頁面。

附錄

項目規模：假設一個訂單系統，每個帳戶每天大約有 10-100 個訂單，幾千個帳戶，最終每個帳戶可以有幾百到幾千個用戶。

更擅長：在不斷增長和變化的需求方面具有前瞻性和靈活性。 性能對於保持硬件部門的低成本也很重要。 熟練勞動力的可用性也是一個因素。

OLTP 或 OLAP ：OLTP

Answer 1

PostgreSQL 在 SQL 特性方面要先進得多。

MySQL 還沒有（而 PostgreSQL 有）的東西：

• 可延遲約束

• 檢查約束 （MySQL 8.0. 16添加了它們，MariaDB 10.2 有它們）

• 全外連接
  MySQL 默默地使用帶有一些語法變化的內部連接：
  https://rextester.com/ADME43793
  

• 橫向連接

• 正則表達式 不適用於 UTF-8 （由MySQL 8.0修復）

• 正則表達式不支持替換或子字符串 （ MySQL 8.0引入）

• 表函數（ select * from my_function() ）

• 公用表表達式 （ MySQL 8.0引入）

• 遞歸查詢 （ MySQL 8.0引入）

• 可寫 CTE

• 窗口函數 （ MySQL 8.0引入）

• 基於函數的索引 （自 MySQL 8.0. 15起支持）

• 部分索引

• 包括索引中的附加列（例如，用於唯一索引）

• 多列統計

• 事務表上的全文搜索 （MySQL 5.6 支持這一點）

• 事務表上的 GIS 功能

• EXCEPT 或 INTERSECT 運算符（MariaDB 有）

• 您不能在同一個 select 語句中兩次使用臨時表

• 您不能在子選擇中使用正在更改的表（更新/刪除/插入）

• 您不能創建使用派生表的視圖 （自 MySQL 8.0 起可能）

   create view x as select * from (select * from y);

• 語句級讀一致性。 需要例如：
  update foo set x = y, y = x或
  update foo set a = b, a = a + 100

• 事務性 DDL

• DDL 觸發器

• 排除約束

• 鍵/值存儲

• 索引完整的 JSON 文檔

• SQL/JSON 路徑表達式（自 Postgres 12 起）

• 范圍類型

• 域

• 數組（包括數組索引）

• 角色（組）來管理用戶權限 （MariaDB有它們，在 MySQL 8.0 中引入）

• 並行查詢（自 Postgres 9.6起）

• 並行索引創建（自 Postgres 11 起）

• 用戶定義的數據類型（包括檢查約束）

• 物化視圖

• 自定義聚合

• 自定義窗口函數

• 正確的boolean數據類型
  _{（將任何可以轉換為非零數的表達式視為“真”不是正確的布爾類型）}

當涉及到空間/GIS 功能時，帶有 PostGIS 的 Postgres 也更有能力。 這是一個很好的比較。

不確定您所說的“易用性”是什么，但有幾個我不想錯過的現代 SQL 功能（CTE、窗口函數）將為我定義“易用性”。

現在，PostgreSQL 並不完美，而且可能是最令人討厭的事情，它為一個繁重的寫入數據庫調整可怕的 VACUUM 進程。

Answer 2

MySQL的查詢優化器還傻嗎？ 在非常復雜的查詢上它仍然非常慢嗎？

所有查詢優化器有時都很愚蠢。 在大多數情況下，PostgreSQL 不那么愚蠢。 PostgreSQL 的一些較新的 SQL 特性（窗口函數、遞歸 WITH 查詢等）非常強大，但如果你有一個愚蠢的 ORM，它們可能無法使用。

項目規模：假設一個訂單系統，每個賬戶每天大約有 10-100 個訂單，幾千個賬戶，最終每個賬戶可以有幾百到幾千個用戶。

聽起來沒有那么大——在一個大盒子的范圍內。

更擅長：在不斷增長和變化的需求方面具有前瞻性和靈活性。

PostgreSQL 有一個強大的開發團隊，擁有一個擴展的貢獻者社區。 發布政策是嚴格的，僅在點發布中修復錯誤。 始終跟蹤 9.1.x 的最新版本的錯誤修復。

MySQL 過去對版本號的態度較為寬松。 這可能會隨着甲骨文的掌權而改變。 我不熟悉各種分叉的政策。

性能對於保持硬件部門的低成本也很重要。

如果硬件成為這個規模項目的主要組成部分，我會感到驚訝。

熟練勞動力的可用性也是一個因素。

那是你的關鍵決定者。 如果你有一個經驗豐富的 Perl + PostgreSQL 黑客團隊閑着，那就使用它。 如果你的人知道 Lisp 和 MySQL，那么就使用它。

OLTP 或 OLAP：OLTP

PostgreSQL 在 OLTP 上一直很強大。

我個人的觀點是 PostgreSQL 郵件列表中充滿了禮貌、樂於助人、知識淵博的人。 您可以與擁有 Terabyte 數據庫的用戶和構建代碼主要部分的黑客直接聯系。 支持的質量非常好。

Answer 3

作為對@a_horse_with_no_name 答案的補充，我想列舉一些我在 PostgreSQL 中非常喜歡的特性：

• 數組數據類型；
• hstore 擴展——對於存儲key->value數據非常有用，可以在該類型的列上創建索引；
• 各種語言擴展——我發現 Python 在非結構化數據處理方面非常有用；
• 語法distinct on ——我認為這應該是 ANSI SQL 特性，對我來說它看起來很自然（與 MySQL 按語法分組相反）；
• 復合類型；
• 記錄類型；
• 繼承；
• 9.3 版功能：
  • 橫向連接- 我從 SQL Server 錯過的一件事（它稱為外部/交叉應用）；
  • 原生 JSON 支持；
  • DDL 觸發器；
  • 遞歸的、 物化的、 可更新的視圖；

Answer 4

PostgreSQL 是一個更成熟的數據庫，它的歷史更長，更符合 ANSI SQL，它的查詢優化器明顯更好。 MySQL 有不同的存儲引擎，例如 MyISAM、InnoDB、in-memory，它們都是不兼容的，因為在一個引擎上運行的 SQL 查詢在另一個引擎上執行時可能會產生語法錯誤。 存儲過程在 PostgreSQL 中更好。