2025年：MySQL vs PostgreSQL
當前位置：點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
在 2025 年的當下，MySQL 無論是在功能特性集，質(zhì)量正確性，性能表現(xiàn)，還是生態(tài)與社區(qū)上都被 PostgreSQL 拉開了差距，而且這個差距還在進一步擴大中。 今天我們就來對 MySQL 與 PostgreSQL 進行一個全方位的對比，從功能，性能，質(zhì)量，生態(tài)來全方位反映這幾年的生態(tài)變化。 功能讓我們先從開發(fā)者最關(guān)注的東西 —— 功能特性開始說起。 新版本昨天，MySQL 發(fā)布了 “創(chuàng)新版本” 9.3[3] 但是看上去和先前的 9.x 一樣，都是些修修補補，看不到什么創(chuàng)新的東西。 搜索尚未發(fā)布的 PostgreSQL 18，你能看到無數(shù)特性預(yù)覽的介紹文章；而搜索 MySQL 9.3，能看到的是社區(qū)對此的抱怨與失望。 MySQL 老司機丁奇看完 ReleaseNote 之后表示，《MySQL創(chuàng)新版正在逐漸失去它的意義》，德哥看后寫了 《MySQL將保持平庸》。 對于 MySQL 的 “創(chuàng)新版本”，Percona CEO， Peter Zaitsev 也發(fā)三篇《MySQL將何去何從[4]》，《Oracle最終還是殺死了MySQL[5]》，《Oracle還能挽救MySQL嗎[6]》，公開表達了對 MySQL 的失望與沮喪。 在最近幾年，MySQL 在新功能上乏善可陳，與突飛猛進的 PostgreSQL 形成了鮮明的對比。 新功能以數(shù)據(jù)庫領(lǐng)域最近兩年最為火爆的增量場景 —— 向量數(shù)據(jù)庫為例。在前兩年的 向量數(shù)據(jù)庫熱潮中，PostgreSQL 生態(tài)里就涌現(xiàn)出了至少六七款向量數(shù)據(jù)庫擴展（ 在當下，PostgreSQL 生態(tài)正在進行著 如火如荼的 DuckDB 縫合大賽 ，
而 MySQL 在這段時間里更新了什么功能呢？一個不支持計算距離與索引的羞辱性 VECTOR 實現(xiàn)[10]；
還有一個企業(yè)版專屬的 JS 存儲過程支持（開源版沒有?。?，而這是 PG 15 年前就可以通過 當 MySQL 還局限在 “關(guān)系型 OLTP 數(shù)據(jù)庫” 的定位時， PostgreSQL 早已經(jīng)放飛自我，從一個關(guān)系型數(shù)據(jù)庫發(fā)展成了一個多模態(tài)的數(shù)據(jù)庫，成為了一個數(shù)據(jù)管理的抽象框架與開發(fā)平臺了。 擴展性來自 CMU 的 Abigale Kim 對主流數(shù)據(jù)庫的可擴展性[11]進行了研究：PostgreSQL 有著所有 DBMS 中最好的 可擴展性（Extensibility），以及其他數(shù)據(jù)庫生態(tài)難望其項背的擴展插件數(shù)量 —— 375+，這還只是 PGXN 注冊在案的實用插件，實際生態(tài)擴展總數(shù)已經(jīng)破千[12]。至少在開源的 PostgreSQL RDS 發(fā)行版 Pigsty 中，就已經(jīng)開箱即用的提供 405 個擴展的 DEB/RPM 包了。
PostgreSQL 有著一個繁榮的擴展生態(tài) —— 地理空間，時間序列，向量檢索，機器學(xué)習(xí)，OLAP分析，全文檢索，圖數(shù)據(jù)庫；這些擴展讓 PostgreSQL 真正成為一專多長的全棧數(shù)據(jù)庫 —— 單一數(shù)據(jù)庫選型便可替代各式各樣的專用組件： MySQL，MongoDB，Kafka，Redis，ElasticSearch，Neo4j，甚至是專用分析數(shù)倉與數(shù)據(jù)湖。
PostgreSQL正在吞噬數(shù)據(jù)庫世界[13] —— 它正在通過插件的方式，將整個數(shù)據(jù)庫世界內(nèi)化其中?！?/span>一切皆用 Postgres[14]” 也已經(jīng)不再是少數(shù)精英團隊的前沿探索，而是成為了一種進入主流視野的最佳實踐。 而在新功能支持上，MySQL 卻顯得十分消極 —— 一個應(yīng)該有大量 Breaking Change 的“創(chuàng)新大版本更新”，不是糊弄人的擺爛特性，就是企業(yè)級的特供雞肋，一個大版本就連雞零狗碎的小修小補都湊不夠數(shù)。 兼容性除了海量擴展外，PostgreSQL 生態(tài)還有更離譜的：兼容功能：你還可以使用擴展或者分支，實現(xiàn)對其他數(shù)據(jù)庫的兼容。
其中，openHalo 對 MySQL 生態(tài)可謂釜底抽薪 —— 在 PG 上直接兼容 MySQL 的線纜協(xié)議，這意味著 MySQL 應(yīng)用可以在不改驅(qū)動/代碼的情況下遷移到 PostgreSQL 上來。 另外，OrioleDB 在原生 PostgreSQL 的基礎(chǔ)上，增加了云原生 Undo 存儲引擎，解決了膨脹/XID回卷問題，并實現(xiàn)了 4x 的吞吐量性能。 這并非紙面上的 PR 稿，這些內(nèi)核/擴展都已經(jīng)全部在 PostgreSQL 發(fā)行版 Pigsty 中作為開箱即用的 RDS 服務(wù)直接可用。在這種全能性能怪獸面前，MySQL 將何去何從？ 性能缺少功能也許并不是一個無法克服的問題 —— 對于一個數(shù)據(jù)庫來說，只要它能將自己的本職工作做得足夠出彩，那么架構(gòu)師總是可以多費些神，用各種其他的數(shù)據(jù)積木一起拼湊出所需的功能。 性能劣化的MYSQLMySQL 曾引以為傲的核心特點便是 性能 —— 至少對于互聯(lián)網(wǎng)場景下的簡單 OLTP CURD 來說，它的性能是非常不錯的。然而不幸地是，這一點也正在遭受挑戰(zhàn)：Percona 的博文《Sakila：你將何去何從[15]》中提出了一個令人震驚的結(jié)論： MySQL 的版本越新，性能反而越差。
根據(jù) Percona 的測試，在 sysbench 與 TPC-C 測試下，最新 MySQL 8.4 版本的性能相比 MySQL 5.7 出現(xiàn)了平均高達 20% 的下降。而 MySQL 專家 Mark Callaghan 進一步進行了 詳細的性能回歸測試[16]，確認了這一現(xiàn)象：
雞肋的分析性能盡管 MySQL 的優(yōu)化器在 8.x 有一些改進，一些復(fù)雜查詢場景下的性能有所改善，但分析與復(fù)雜查詢本來就不是 MySQL 的長處與適用場景，只能說聊勝于無。相反，如果作為基本盤的 OLTP CRUD 性能出了這么大的折損，那確實是完全說不過去的。
而另一方面，PostgreSQL 在 DuckDB 系列擴展與列存擴展的加持下，甚至可以達到比肩 ClickHouse 的分析性能。
Peter Zaitsev 在博文《Oracle最終還是殺死了MySQL[18]》中評論：“與 MySQL 5.6 相比，MySQL 8.x 單線程簡單工作負載上的性能出現(xiàn)了大幅下滑。你可能會說增加功能難免會以犧牲性能為代價，但 MariaDB 的性能退化要輕微得多，而 PostgreSQL 甚至能在 新增功能的同時顯著提升性能[19]”。 穩(wěn)步提升的PostgreSQL性能MySQL的性能隨版本更新而逐步衰減，但在同樣的性能回歸測試中，PostgreSQL 性能卻可以隨版本更新有著穩(wěn)步提升。特別是在最關(guān)鍵的寫入吞吐性能上，最新的 PostgreSQL 17beta1 相比六年前的 PG 10 甚至有了 30% ～ 70% 的提升。
在 Mark Callaghan 的 性能橫向?qū)Ρ?/span>[20] （sysbench 吞吐場景） 中，我們可以看到五年前 PG 11 與 MySQL 5.6 的性能比值（藍），與當下 PG 16 與 MySQL 8.0.34 的性能比值（紅）。PostgreSQL 和 MySQL 的性能差距在這五年間拉的越來越大。
幾年前的業(yè)界共識是 PostgreSQL 與 MySQL 在 簡單 OLTP CRUD 場景 下的性能基本相同。然而此消彼長之下，現(xiàn)在 PostgreSQL 的性能已經(jīng)遠遠甩開 MySQL 了。 PostgreSQL 的各種讀吞吐量相比 MySQL 高 25% ～ 100% 不等，在一些寫場景下的吞吐量更是達到了 200% 甚至 500% 的恐怖水平。 在真實場景中的對比一個有趣的佐證是知名開源項目 JuiceFS[21] 對不同數(shù)據(jù)庫作為元數(shù)據(jù)引擎的性能測試。
在這個例子中，我們可以很清晰的看出 MySQL 和 PostgreSQL 在一個真實三方評測中的性能差距。
更多更詳細關(guān)于 PostgreSQL 與 MySQL 與 PostgreSQL 的性能評測，我建議各位參考 Mark Callaghan 發(fā)表在 Small Datum 上的文章。這是前 Google / Meta 的 MySQL Tech Lead 。 盡管他的主要職業(yè)生涯在與 MySQL，Oracle，MongoDB 打交道，并非 PostgreSQL 專家，但他嚴謹?shù)臏y試方法與結(jié)果分析為讀者帶來了許多數(shù)據(jù)庫性能方面的洞見，比瞎評測的偽專家高到不知道哪里去了。 質(zhì)量如果新版本只是性能不好，總歸還有辦法來優(yōu)化修補。但如果是質(zhì)量出了問題，那真就是無可救藥了。 正確性例如，Percona 最近剛剛在 MySQL 8.0.38 以上的版本（8.4.x, 9.0.0）中發(fā)現(xiàn)了一個 嚴重Bug[23] —— 如果數(shù)據(jù)庫里表超過 1萬張，那么重啟的時候 MYSQL 服務(wù)器會直接崩潰！ 一個數(shù)據(jù)庫里有1萬張表并不常見，但也并不罕見 —— 特別是當用戶使用了一些分表方案，或者應(yīng)用會動態(tài)創(chuàng)建表的時候。而直接崩潰顯然是可用性故障中最嚴重的一類情形。 但 MySQL 的問題不僅僅是幾個軟件 Bug，而是根本性的問題 —— 《MySQL 糟糕的 ACID 正確性》指出，在正確性這個體面數(shù)據(jù)庫產(chǎn)品必須的基本屬性上，MySQL 的表現(xiàn)一塌糊涂。 權(quán)威的分布式事務(wù)測試組織 JEPSEN[24] 研究發(fā)現(xiàn)，MySQL 文檔聲稱實現(xiàn)的 可重復(fù)讀/RR 隔離等級，實際提供的正確性保證要弱得多 —— MySQL 8.0.34 默認使用的 RR 隔離等級實際上并不可重復(fù)讀，甚至既不原子也不單調(diào)，連 單調(diào)原子視圖/MAV 的基本水平都不滿足。這意味著 MySQL 的 RR 隔離等級實際上還不如絕大多數(shù) DBMS 的 RC 隔離等級（MAV）。
MySQL 的 ACID 存在缺陷，且與文檔承諾不符 —— 而輕信這一虛假承諾可能會導(dǎo)致嚴重的正確性問題，例如數(shù)據(jù)錯漏與對賬不平。對于一些數(shù)據(jù)完整性很關(guān)鍵的場景 —— 例如金融，這一點是無法容忍的。 此外，能“避免”這些異常的 MySQL 可串行化/SR 隔離等級難以生產(chǎn)實用，也非官方文檔與社區(qū)認可的最佳實踐；盡管專家開發(fā)者可以通過在查詢中顯式加鎖來規(guī)避此類問題，但這樣的行為極其影響性能，而且容易出現(xiàn)死鎖。 與此同時，PostgreSQL 在 9.1 引入的 可串行化快照隔離（SSI） 算法可以用極小的性能代價提供完整可串行化隔離等級 —— 而且 PostgreSQL 的 SR 在正確性實現(xiàn)上毫無瑕疵 —— 這一點即使是 Oracle 也難以企及。 李海翔教授在《一致性八仙圖》論文中，系統(tǒng)性地評估了主流 DBMS 隔離等級的正確性，圖中藍/綠色代表正確用規(guī)則/回滾避免異常；黃A代表異常，越多則正確性問題就越多；紅“D”指使用了影響性能的死鎖檢測來處理異常，紅D越多性能問題就越嚴重；
不難看出，這里正確性最好（無黃A）的實現(xiàn)是 PostgreSQL SR，與基于PG的 CockroachDB SR，其次是略有缺陷 Oracle SR；主要都是通過機制與規(guī)則避免并發(fā)異常；而 MySQL 出現(xiàn)了大面積的黃A與紅D，正確性水平與實現(xiàn)手法糙地不忍直視。 做正確的事很重要，而正確性是不應(yīng)該拿來做利弊權(quán)衡的。在這一點上，開源關(guān)系型數(shù)據(jù)庫兩巨頭 MySQL 和 PostgreSQL 在早期實現(xiàn)上就選擇了兩條截然相反的道路： MySQL 追求性能而犧牲正確性；而學(xué)院派的 PostgreSQL 追求正確性而犧牲了性能。 在互聯(lián)網(wǎng)風(fēng)口上半場中，MySQL 因為性能優(yōu)勢占據(jù)先機乘風(fēng)而起。但當性能不再是核心考量時，正確性就成為了 MySQL 的致命出血點。 更為可悲的是，MySQL 連犧牲正確性換來的性能，都已經(jīng)不再占優(yōu)了，這著實讓人唏噓不已。 完備性SQL 特性與標準支持：PostgreSQL 一直以高度符合 SQL 標準著稱，支持復(fù)雜查詢、窗口函數(shù)、公共表表達式（CTE）、遞歸查詢、完整的外鍵約束等功能，并且實現(xiàn)了豐富的 SQL/JSON 標準和自定義函數(shù)。 MySQL 過去在標準支持上相對落后，但自 8.0 版本起補齊了一些短板：如支持窗口函數(shù)和 CTE（包括遞歸 CTE）等，使其在查詢特性上拉近了距離。 但是魔鬼在細節(jié)中，許多看上去 “你有我也有” 的功能，內(nèi)在的實現(xiàn)水準是完全不一樣的。
以 Ecoding 字符編碼與 Collation 排序規(guī)則為例，這是很典型的企業(yè)級應(yīng)用需要的多語言關(guān)鍵特性。PostgreSQL 在 ICU 支持下提供了 42 種字符集編碼與 815 種排序規(guī)則支持，覆蓋了幾乎你能想象到的一切排序方法。 而 MySQL 在基本上就只有 五種字符集和幾十個基于此的排序規(guī)則[26]。這是一個很好的微觀細節(jié)樣本，體現(xiàn)出 PostgreSQL 與 MySQL 在細節(jié)上的用心程度與差異。 生態(tài)對一項技術(shù)而言，用戶的規(guī)模直接決定了生態(tài)的繁榮程度。瘦死的駱駝比馬大，爛船也有三斤釘。 MySQL 曾經(jīng)搭乘互聯(lián)網(wǎng)東風(fēng)扶搖而起，攢下了豐厚的家底，它的 Slogan 就很能說明問題 —— “世界上最流行的開源關(guān)系型數(shù)據(jù)庫”。 開發(fā)者MySQL 的 Slogan 是 “世界上最流行的開源關(guān)系型數(shù)據(jù)庫”，但似乎現(xiàn)在并沒有多少權(quán)威數(shù)據(jù)能支持這個說法。 相反的是，在 StackOverflow 過去八年的全球開發(fā)者調(diào)研中，我們可以觀察到 PostgreSQL 在開發(fā)者中的使用率節(jié)節(jié)攀升，并于 2023 年第一次超過 MySQL ，成為最流行的數(shù)據(jù)庫。
從各個角度上來看，MySQL “最流行” 的稱號已經(jīng)名不副實了。而 PostgreSQL 已經(jīng)成為這幾年最流行的數(shù)據(jù)庫，并且不需要不需要開源/關(guān)系型等定語修飾。
在需求度，喜愛度，流行度上，PostgreSQL 在過去八年的變化趨勢非常明顯：
在最為活躍的前端開發(fā)者生態(tài)中，PostgreSQL 已經(jīng)憑借豐富的功能特性，以壓倒性優(yōu)勢成為最受歡迎的的數(shù)據(jù)庫。例如，在 Vercel 支持的 7 款存儲服務(wù)上，四個是 Postgres 衍生（Neon,Supabase,Nile,Gel），兩個 Redis 衍生，一個 DuckDB ，完全不見 MySQL 的蹤影。
而根據(jù) DBDB.io 的統(tǒng)計數(shù)據(jù)，派生自 PostgreSQL 的數(shù)據(jù)庫項目也顯著超過了 MySQL。 廠商最直觀的數(shù)據(jù)： AWS RDS 上 PostgreSQL 實例的數(shù)量與 MySQL 實例的數(shù)量已經(jīng)達到了 6:4 ，也就是 PG 實例的數(shù)量已經(jīng)比 MySQL 要多 50% 了。 即使是在 MYSQL 曾經(jīng)占據(jù)壓倒性優(yōu)勢的中國大陸，來自阿里云 RDS 實例數(shù)的樣本也說明 MYSQL:PG 從前幾年的 10:1 快速縮小到 5:1，并且增量上 PG 也已經(jīng)超過 MYSQL 了。 從商業(yè)角度看，云廠商已經(jīng)將重注下在了 PostgreSQL，而非 MySQL 上。 例如 AWS RDS （MySQL+PG）產(chǎn)品經(jīng)理是 PostgreSQL 社區(qū)核心組成員 Jonathan Katz，也是最近 pg/pgvector 在向量數(shù)據(jù)庫領(lǐng)域崛起關(guān)鍵推手之一。 最近的 Aurora 新品分布式 DSQL 只有 PostgreSQL 兼容，沒搞 MySQL 的，而以前這種事從來都是 MySQL 優(yōu)先，這次似乎直接放棄 MYSQL 支持了。 Google 的 OLTP 數(shù)據(jù)庫 AlloyDB 也選擇完全兼容 PostgreSQL ，并且也在 Spanner 中提供 PostgreSQL 了。 國內(nèi)云廠商例如阿里云也選擇押寶 PostgreSQL 分支路線，例如獲得信創(chuàng)資質(zhì)認證的 PolarDB 2.0 （Oracle）兼容其實就是基于 PolarDB PG 二次分枝的版本。 資本市場最近的 大額融資紀錄，也基本發(fā)生在 PostgreSQL 生態(tài)中。
而 MySQL 生態(tài)屈指可數(shù)，基本只有 SingleStore，TiDB ，而原本生態(tài)中全村的希望 MariaDB 則一路跌的干脆直接要退市私有化了。 大型用例對于制造業(yè)，金融，非互聯(lián)網(wǎng)場景，PostgreSQL 憑借其強大的功能特性與正確性，已經(jīng)成為了許多大型企業(yè)的首選數(shù)據(jù)庫。 例如在我任職 Apple 期間，我們部門使用 PostgreSQL 存儲所有工廠的工業(yè)互聯(lián)網(wǎng)數(shù)據(jù)并進行數(shù)據(jù)分析。包括我們部門在內(nèi)的許多項目都在使用 PostgreSQL，甚至有一個內(nèi)部的社區(qū)與興趣小組。 大型互聯(lián)網(wǎng)公司受制于歷史路徑依賴于慣性仍然保留有大量 MySQL，但也基本開始兩頭下注，很多 PostgreSQL 的支持者都是微軟，AWS，Apple，Google 這樣的大公司。而在新興創(chuàng)業(yè)公司中，PostgreSQL 更是已經(jīng)取得顯著優(yōu)勢。 例如，Cursor、 Dify、Notion 這樣的 AI 新寵都默認使用 PostgreSQL 作為元數(shù)據(jù)存儲。支付明星企業(yè) Strip 也在一些系統(tǒng)中使用 PostgreSQL 進行分析。 Cloudflare 與 Vercel 的內(nèi)部系統(tǒng)大量使用了 PostgreSQL， Node.js 社區(qū)項目也明顯對 PostgreSQL 有偏好（例如 Prisma ORM 對PG 支持更完善）。很多開源新項目都默認選擇 PostgreSQL 作為其首選數(shù)據(jù)庫 —— 如果不是唯一選擇的話。 MYSQL 到底怎么了？究竟是誰殺死了 MySQL，難道是 PostgreSQL 嗎？Peter Zaitsev 在《Oracle最終還是殺死了MySQL[27]》一文中控訴 —— Oracle 的不作為與瞎指揮最終害死了 MySQL；并在后續(xù)《Oracle還能挽救MySQL嗎[28]》一文中指出了真正的根因： MySQL 的知識產(chǎn)權(quán)被 Oracle 所擁有，它不是像 PostgreSQL 那種 “由社區(qū)擁有和管理” 的數(shù)據(jù)庫，也沒有 PostgreSQL 那樣廣泛的獨立公司貢獻者。不論是 MySQL 還是其分叉 MariaDB，它們都不是真正意義上像 Linux，PostgreSQL，Kubernetes 這樣由社區(qū)驅(qū)動的的原教旨純血開源項目，而是由單一商業(yè)公司主導(dǎo)。 比起向一個商業(yè)競爭對手貢獻代碼，白嫖競爭對手的代碼也許是更為明智的選擇 —— AWS 和其他云廠商利用 MySQL 內(nèi)核參與數(shù)據(jù)庫領(lǐng)域的競爭，卻不回饋任何貢獻。于是作為競爭對手的 Oracle 也不愿意再去管理好 MySQL，而干脆自己也參與進來搞云 —— 僅僅只關(guān)注它自己的 MySQL heatwave 云版本，就像 AWS 僅僅專注于其 RDS 管控和 Aurora 服務(wù)一樣。在 MySQL 社區(qū)凋零的問題上，云廠商也難辭其咎。 總結(jié)盡管我是 PostgreSQL 的堅定支持者，但我也贊同 Peter Zaitsev 的觀點： “如果 MySQL 徹底死掉了，開源關(guān)系型數(shù)據(jù)庫實際上就被 PostgreSQL 一家壟斷了，而壟斷并不是一件好事，因為它會導(dǎo)致發(fā)展停滯與創(chuàng)新減緩。PostgreSQL 要想進入全盛狀態(tài)，有一個 MySQL 作為競爭對手并不是壞事” 至少，MySQL 可以作為一個鞭策激勵，讓 PostgreSQL 社區(qū)保持凝聚力與危機感，不斷提高自身的技術(shù)水平，并繼續(xù)保持開放、透明、公正的社區(qū)治理模式，從而持續(xù)推動數(shù)據(jù)庫技術(shù)的發(fā)展。
MySQL 曾經(jīng)也輝煌過，也曾經(jīng)是“開源軟件”的一桿標桿，但再精彩的演出也會落幕。MySQL 正在死去 —— 更新疲軟，功能落后，性能劣化，質(zhì)量出血，生態(tài)萎縮，此乃天命，實非人力所能改變。而 PostgreSQL ，將帶著開源軟件的初心與愿景繼續(xù)堅定前進 —— 它將繼續(xù)走 MySQL 未走完的路，寫 MySQL 未寫完的詩篇。 References
閱讀原文：https://mp.weixin.qq.com/s/NTd9_QRJRIu_XLbZ1zv7KA 該文章在 2025/4/17 18:02:19 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
?
