作者介紹-陳天舟

首先在全球范圍內，MySQL 一直是領先于 PostgreSQL (下文簡稱 PG) 的。下圖是 DB-Engines 的趨勢圖，雖然 PG 是近 10 年增長最快的數據庫，但 MySQL 依然保持著優勢。

再來看一下 Google Trends 過去一年的對比

MySQL 也依然是明顯領先的。而進一步看一下地域分布的話

絕大多數地區依然是 MySQL 領先，份額對比在 60:40 ~ 70:30 之間；少數幾個國家如俄羅斯不分伯仲；印度的對比是 85:15；而中國則是達到了 96:4，也是 Google Trends 上差異最明顯的國家。

筆者從 2009 年左右開始學習數據庫相關知識，接觸到了 MySQL 5.1 和 PG 8.x。而深度在工作中使用則是 2013 年，那時加入 Google Cloud SQL 開始維護數據庫，MySQL 從 5.5 開始，到之后 2017 年 Cloud SQL 推出了 PG 服務，從 9.6 開始，后來一直同時維護 Google 內部的 MySQL 和 PG 分支，也就一直關注著兩邊的發展。18 年回國后，進一步熟悉了國內的生態。 下面就來嘗試分析一下 MySQL 在中國流行度遙遙領先于 PG 的原因。

Windows

MySQL 在 1998 年就提供了 Windows 版本，而 PostgreSQL 則到了 2005 年才正式推出。之前讀到的原因是 Windows 早期的版本一直無法很好支持 PostgreSQL 的進程模型。

上手門檻

MySQL 上手更簡單，舉幾個例子：

連 PG，一定需要指定數據庫，而 MySQL 就不需要。psql 大家碰到的問題是嘗試連接時報錯 FATAL Database xxx does not exist。而 mysql 碰到的問題是連接上去后，執行查詢再提示 no database selected。

訪問控制的配置，首先 PG 和 MySQL 都有用戶系統，但 PG 還要配置一個額外的 pg_hba (host-based authentication) 文件。

MySQL 的層級關系是：實例 -> 數據庫 -> 表，而 PG 的關系是：實例（也叫集群）> 數據庫 > Schema > 表。PG 多了一層，而且從行為表現上，PG 的 schema 類似于 MySQL 數據庫，而 PG 的數據庫類似于 MySQL 的實例。PG 的這個額外層級在絕大多數場景是用不到的，大家從習慣上還是喜歡用數據庫作為分割邊界，而不是 schema。所以往往 PG 數據庫下，也就一個 public schema，這多出來的一層 schema 就是額外的負擔。

因為上面機制的不同，PG 是無法直接做跨庫查詢的，早年要通過 dblink 插件，后來被 FDW (foreign data wrapper) 取代。

PG 有更加全面的權限體系，數據庫對象都有明確的所有者，但這也導致在做測試時，更經常碰到權限問題。

雖然 PostgreSQL 的設計更加嚴謹，但也更容易把人勸退。就像問卷設計的一個技巧是第一題放一個無腦就能答上來的二選一，這個的目的在于讓對方開始答題。

性能

最早 Google 搜索和廣告業務都是跑在 MySQL 上的，我讀到過當時選型的備忘。其實一開始團隊是傾向于 PG 的（我猜測是 PG 的工程質量更加符合團隊的技術品味），但后來測試發現 MySQL 的性能要好不少，所以就選型了 MySQL。 現在兩者的性能對比已經完全不一樣了，而且性能和業務關聯性很強，取決于 SQL 復雜度，并發，延遲這些不同的組合。目前在大部分場景下，MySQL 和 PG 的性能是相當的。有興趣可以閱讀 Mark Callaghan (https://smalldatum.blogspot.com/) 的文章。

互聯網

最重要的是 LAMP 技術棧，Linux + Apache + MySQL + PHP，誕生于 1998 年，和互聯網崛起同步，LAMP 技術棧的普及也帶火了 MySQL。這個技術棧的綁定是如此之深，所以時至今日，MySQL 官方客戶端 MySQL Workbench 也還是不及 phpMyAdmin 流行。

大廠的號召力

前面提到的 Mark Callaghan 一開始在 Google 的 MySQL 團隊，他們給生態做了很多貢獻，后來 Google 內部開始用 Spanner 替換 MySQL，Mark 他們就跑到了 Facebook 繼續做，又進一步發展了 MySQL 的生態，像當時互聯網公司都需要的高可用方案 MHA (Master High Availability) 就是 Mark 在 FB 時期打磨成熟的。當時整個互聯網技術以 Google 為瞻，傳播鏈差不多是 Google > Facebook / Twitter > 國內互聯網大廠 > 其他中小廠。MySQL 在互聯網公司的壟斷就這樣形成了。 相對的，那段時間 PG 有影響力的文章不多，我唯一有印象的是 Instagram 分享他們 sharding 的方案，提到用的是 PostgreSQL (https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c)。

生態

有了大量使用后，自然就有人去解決碰到的各種問題。先是 InnoDB 橫空出世，解決了事務和性能問題。主從，中間件分庫分表方案解決了海量服務的擴展和高可用問題。各種 MySQL 相關書籍，培訓資料也冒了出來，應該不少人都讀過高性能 MySQL (High Performance MySQL) 這本書。

業界有 Percona 這樣專注于做 MySQL 技術咨詢的公司，他們還研發了一系列工具，比如做大表變更的 pt-online-schema-change（后來 GitHub 還發布了改良版 gh-ost)，做備份的 xtrabackup。 國內也做了不少的貢獻，阿里給上游貢獻了許多 replication 的改進。SQL 審核優化這塊，有去哪兒研發的 Inception，小米團隊的 SOAR。Parser 有 PingCAP 的 MySQL Parser。 相對而言 PG 在工具鏈的生態還是差不少，比如 PG 生態里沒有開箱即用的 Parser，沒有 Parser 也就無法做 SQL 審核。Bytebase 在實現相關功能時，就只能從頭開始做。當然這也成為了 Bytebase 產品的核心競爭力，我們是市面上對 PG 變更審核，查詢脫敏支持最好的工具，除了大表變更外，功能完全對標 MySQL。

總結和展望

回到中國 MySQL 遠比 PostgreSQL 流行的原因，在上面所有列出的要素里，我覺得最核心的還是第一條，MySQL 很早就能跑在 Windows 上，而 PG 不能。因為有了能跑 Windows 這個點，MySQL 成為了 LAMP 的一部分，到后來成為了支撐整個互聯網的基石。當時國內大家手頭裝的都是 windows 操作系統，要開發 web 應用，都用 LAMP 架構，就順便把 MySQL 帶上了。 此外國內還有更明顯的頭部效應。國內所有互聯網公司的技術體系都源自阿里，比如拿研發環境來說，SIT (System Integration Test) 是我回國加入螞蟻后才接觸到的名詞，但后來在其他各個地方又都反復遇到。數據庫方案也是如此，全套照搬了阿里的 MySQL 方案。就連技術職級也是，找工作先確認對標 P 幾。

就在上月，MySQL 5.7 宣布了 EOL，算是給 MySQL 5 系，這個支撐了過去 15 年中國互聯網的功勛做了一個告別。 隨著 MySQL 的辭舊，PG 的崛起，在這 AI 的黎明，VR 的前夜，下一個 15 年，MySQL 和 PG 之間相愛相殺的故事又該會如何演繹呢。

編輯：黃飛