首先在全球范圍內(nèi)，MySQL 一直是領(lǐng)先于 PostgreSQL (下文簡(jiǎn)稱 PG) 的。下圖是 DB-Engines 的趨勢(shì)圖，雖然 PG 是近 10 年增長(zhǎng)最快的數(shù)據(jù)庫(kù)，但 MySQL 依然保持著優(yōu)勢(shì)。
再來(lái)看一下 google Trends 過(guò)去一年的對(duì)比：
MySQL 也依然是明顯領(lǐng)先的。而進(jìn)一步看一下地域分布的話：
絕大多數(shù)地區(qū)依然是 MySQL 領(lǐng)先，份額對(duì)比在 60:40 ~ 70:30 之間；少數(shù)幾個(gè)國(guó)家如俄羅斯不分伯仲；印度的對(duì)比是 85:15；而中國(guó)則是達(dá)到了 96:4，也是 Google Trends 上差異最明顯的國(guó)家。
筆者從 2009 年左右開(kāi)始學(xué)習(xí)數(shù)據(jù)庫(kù)相關(guān)知識(shí)，接觸到了 MySQL 5.1 和 PG 8.x。而深度在工作中使用則是 2013 年，那時(shí)加入 Google Cloud SQL 開(kāi)始維護(hù)數(shù)據(jù)庫(kù)，MySQL 從 5.5 開(kāi)始，到之后 2017 年 Cloud SQL 推出了 PG 服務(wù)，從 9.6 開(kāi)始，后來(lái)一直同時(shí)維護(hù) Google 內(nèi)部的 MySQL 和 PG 分支，也就一直關(guān)注著兩邊的發(fā)展。18 年回國(guó)后，進(jìn)一步熟悉了國(guó)內(nèi)的生態(tài)。
下面就來(lái)嘗試分析一下 MySQL 在中國(guó)流行度遙遙領(lǐng)先于 PG 的原因。
一、windows
MySQL 在 1998 年就提供了 Windows 版本，而 PostgreSQL 則到了 2005 年才正式推出。之前讀到的原因是 Windows 早期的版本一直無(wú)法很好支持 PostgreSQL 的進(jìn)程模型。
二、上手門檻
MySQL 上手更簡(jiǎn)單，舉幾個(gè)例子：
- 連 PG，一定需要指定數(shù)據(jù)庫(kù)，而 MySQL 就不需要。psql 大家碰到的問(wèn)題是嘗試連接時(shí)報(bào)錯(cuò) FATAL Database xxx does not exist。而 mysql 碰到的問(wèn)題是連接上去后，執(zhí)行查詢?cè)偬崾?no database selected。
- 訪問(wèn)控制的配置，首先 PG 和 MySQL 都有用戶系統(tǒng)，但 PG 還要配置一個(gè)額外的 pg_hba (host-based authentication) 文件。
- MySQL 的層級(jí)關(guān)系是：實(shí)例 → 數(shù)據(jù)庫(kù) → 表，而 PG 的關(guān)系是：實(shí)例（也叫集群）> 數(shù)據(jù)庫(kù) > Schema > 表。PG 多了一層，而且從行為表現(xiàn)上，PG 的 schema 類似于 MySQL 數(shù)據(jù)庫(kù)，而 PG 的數(shù)據(jù)庫(kù)類似于 MySQL 的實(shí)例。PG 的這個(gè)額外層級(jí)在絕大多數(shù)場(chǎng)景是用不到的，大家從習(xí)慣上還是喜歡用數(shù)據(jù)庫(kù)作為分割邊界，而不是 schema。所以往往 PG 數(shù)據(jù)庫(kù)下，也就一個(gè) public schema，這多出來(lái)的一層 schema 就是額外的負(fù)擔(dān)。
- 因?yàn)樯厦鏅C(jī)制的不同，PG 是無(wú)法直接做跨庫(kù)查詢的，早年要通過(guò) dblink 插件，后來(lái)被 FDW (foreign data wrApper) 取代。
- PG 有更加全面的權(quán)限體系，數(shù)據(jù)庫(kù)對(duì)象都有明確的所有者，但這也導(dǎo)致在做測(cè)試時(shí)，更經(jīng)常碰到權(quán)限問(wèn)題。
雖然 PostgreSQL 的設(shè)計(jì)更加嚴(yán)謹(jǐn)，但也更容易把人勸退。就像問(wèn)卷設(shè)計(jì)的一個(gè)技巧是第一題放一個(gè)無(wú)腦就能答上來(lái)的二選一，這個(gè)的目的在于讓對(duì)方開(kāi)始答題。
三、性能
最早 Google 搜索和廣告業(yè)務(wù)都是跑在 MySQL 上的，我讀到過(guò)當(dāng)時(shí)選型的備忘。其實(shí)一開(kāi)始團(tuán)隊(duì)是傾向于 PG 的（我猜測(cè)是 PG 的工程質(zhì)量更加符合團(tuán)隊(duì)的技術(shù)品味），但后來(lái)測(cè)試發(fā)現(xiàn) MySQL 的性能要好不少，所以就選型了 MySQL。
現(xiàn)在兩者的性能對(duì)比已經(jīng)完全不一樣了，而且性能和業(yè)務(wù)關(guān)聯(lián)性很強(qiáng)，取決于 SQL 復(fù)雜度，并發(fā)，延遲這些不同的組合。目前在大部分場(chǎng)景下，MySQL 和 PG 的性能是相當(dāng)?shù)摹Ｓ信d趣可以閱讀 Mark Callaghan (https://smalldatum.blogspot.com/) 的文章。
四、互聯(lián)網(wǎng)
最重要的是 LAMP 技術(shù)棧，linux + Apache + MySQL + php，誕生于 1998 年，和互聯(lián)網(wǎng)崛起同步，LAMP 技術(shù)棧的普及也帶火了 MySQL。這個(gè)技術(shù)棧的綁定是如此之深，所以時(shí)至今日，MySQL 官方客戶端 MySQL Workbench 也還是不及 phpMyAdmin 流行。
五、大廠的號(hào)召力
前面提到的 Mark Callaghan 一開(kāi)始在 Google 的 MySQL 團(tuán)隊(duì)，他們給生態(tài)做了很多貢獻(xiàn)，后來(lái) Google 內(nèi)部開(kāi)始用 Spanner 替換 MySQL，Mark 他們就跑到了 Facebook 繼續(xù)做，又進(jìn)一步發(fā)展了 MySQL 的生態(tài)，像當(dāng)時(shí)互聯(lián)網(wǎng)公司都需要的高可用方案 MHA (Master High AvAIlability) 就是 Mark 在 FB 時(shí)期打磨成熟的。當(dāng)時(shí)整個(gè)互聯(lián)網(wǎng)技術(shù)以 Google 為瞻，傳播鏈差不多是 Google > Facebook / Twitter > 國(guó)內(nèi)互聯(lián)網(wǎng)大廠 > 其他中小廠。MySQL 在互聯(lián)網(wǎng)公司的壟斷就這樣形成了。
相對(duì)的，那段時(shí)間 PG 有影響力的文章不多，我唯一有印象的是 Instagram 分享他們 sharding 的方案，提到用的是 PostgreSQL (https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c)。
六、生態(tài)
有了大量使用后，自然就有人去解決碰到的各種問(wèn)題。先是 InnoDB 橫空出世，解決了事務(wù)和性能問(wèn)題。主從，中間件分庫(kù)分表方案解決了海量服務(wù)的擴(kuò)展和高可用問(wèn)題。各種 MySQL 相關(guān)書籍，培訓(xùn)資料也冒了出來(lái)，應(yīng)該不少人都讀過(guò)高性能 MySQL (High Performance MySQL) 這本書。
業(yè)界有 Percona 這樣專注于做 MySQL 技術(shù)咨詢的公司，他們還研發(fā)了一系列工具，比如做大表變更的 pt-online-schema-change（后來(lái) Github 還發(fā)布了改良版 gh-ost)，做備份的 xtrabackup。
國(guó)內(nèi)也做了不少的貢獻(xiàn)，阿里給上游貢獻(xiàn)了許多 replication 的改進(jìn)。SQL 審核優(yōu)化這塊，有去哪兒研發(fā)的 Inception，小米團(tuán)隊(duì)的 SOAR。Parser 有 PingCAP 的 MySQL Parser。
相對(duì)而言 PG 在工具鏈的生態(tài)還是差不少，比如 PG 生態(tài)里沒(méi)有開(kāi)箱即用的 Parser，沒(méi)有 Parser 也就無(wú)法做 SQL 審核。Bytebase 在實(shí)現(xiàn)相關(guān)功能時(shí)，就只能從頭開(kāi)始做。當(dāng)然這也成為了 Bytebase 產(chǎn)品的核心競(jìng)爭(zhēng)力，我們是市面上對(duì) PG 變更審核，查詢脫敏支持最好的工具，除了大表變更外，功能完全對(duì)標(biāo) MySQL。
總結(jié)和展望
回到中國(guó) MySQL 遠(yuǎn)比 PostgreSQL 流行的原因，在上面所有列出的要素里，我覺(jué)得最核心的還是第一條，MySQL 很早就能跑在 Windows 上，而 PG 不能。因?yàn)橛辛四芘?Windows 這個(gè)點(diǎn)，MySQL 成為了 LAMP 的一部分，到后來(lái)成為了支撐整個(gè)互聯(lián)網(wǎng)的基石。當(dāng)時(shí)國(guó)內(nèi)大家手頭裝的都是 windows 操作系統(tǒng)，要開(kāi)發(fā) web 應(yīng)用，都用 LAMP 架構(gòu)，就順便把 MySQL 帶上了。
此外國(guó)內(nèi)還有更明顯的頭部效應(yīng)。國(guó)內(nèi)所有互聯(lián)網(wǎng)公司的技術(shù)體系都源自阿里，比如拿研發(fā)環(huán)境來(lái)說(shuō)，SIT (System Integration Test) 是我回國(guó)加入螞蟻后才接觸到的名詞，但后來(lái)在其他各個(gè)地方又都反復(fù)遇到。數(shù)據(jù)庫(kù)方案也是如此，全套照搬了阿里的 MySQL 方案。就連技術(shù)職級(jí)也是，找工作先確認(rèn)對(duì)標(biāo) P 幾。
就在上月，MySQL 5.7 宣布了 EOL，算是給 MySQL 5 系，這個(gè)支撐了過(guò)去 15 年中國(guó)互聯(lián)網(wǎng)的功勛做了一個(gè)告別。
隨著 MySQL 的辭舊，PG 的崛起，在這 AI 的黎明，VR 的前夜，下一個(gè) 15 年，MySQL 和 PG 之間相愛(ài)相殺的故事又該會(huì)如何演繹呢。
作者丨天舟
來(lái)源丨公眾號(hào)：Bytebase（ID：Bytebase）
