兩年前 MySQL 9.0 發(fā)布的時(shí)候，我寫了一篇《》當(dāng)時(shí) Oracle 敲鑼打鼓搞了個(gè)創(chuàng)新版，加個(gè) VECTOR 數(shù)據(jù)類型就敢吹成 “AI 時(shí)代的 MySQL”。

我當(dāng)時(shí)一看：這玩意就是一個(gè) BLOB 換皮。沒有距離函數(shù)，沒有向量索引，除了能往列里存一堆浮點(diǎn)數(shù)之外什么也干不了。之后的兩年，9.0 到 9.6，七個(gè) Innovation Release，每季度一個(gè)。Percona 看了一眼這七個(gè)版本，一個(gè)都沒跟。PMM 遙測(cè)數(shù)據(jù)顯示 Innovation Release 采用率常年在 1% 附近徘徊，擠不進(jìn)統(tǒng)計(jì)。全球最大的 MySQL 第三方生態(tài)公司，用沉默投了票。

為什么突然要聊 9.7？因?yàn)?9.7 是 MySQL 9.x 系列的第一個(gè) LTS 版本：長(zhǎng)期支持版，5 年 Premier + 3 年 Extended。之前的七個(gè) Innovation Release 都是季拋型的過渡品，Percona 不跟，用戶不碰，大家都在等這個(gè) LTS 落地。而且 MySQL 8.0 馬上就要在 2026 年 4 月 EOL 了，存量用戶必須遷移，9.7 幾乎是唯一的前進(jìn)方向。

一些公眾號(hào)主理人已經(jīng)開始震驚起來了——“MySQL 9.7 發(fā)布！性能飛躍！”“讓 MySQL 進(jìn)入 AI 時(shí)代！”——雖然這玩意到現(xiàn)在（2026 年 4 月）連 GA 都還沒出，只是 3 月底放了個(gè) Early Access 的測(cè)試二進(jìn)制。我反正拉下來試了試——

鍋里還是那碗冷飯。

花架子依舊的向量能力

MYSQL 9.7 參考手冊(cè)第 14.21 章 Vector Functions， 整個(gè)向量部分，沒有向量索引，沒有最近鄰搜索，向量列不能做主鍵、外鍵、唯一鍵，不支持聚合函數(shù)。唯一有實(shí)際意義的功能函數(shù) Distance，竟然還是收費(fèi)特性。

老馮很納悶兒，就這么一個(gè)函數(shù)，這種雞零狗碎的東西，都要藏著掖著，放在商業(yè)版里特意惡心用戶嗎？

MySQL 何至于此？連自家生態(tài)都看不下去了。MariaDB 11.7 去年底就上了原生 VECTOR INDEX + HNSW；TiDB 做了向量索引 Beta；PlanetScale 用 SPANN 算法自己造了一套；Google Cloud SQL for MySQL 用 ScaNN 搞了向量索引；VillageSQL 直接 fork 了 MySQL 8.4 專門做向量；連個(gè)人開發(fā)者都寫了第三方向量插件。Oracle 自己不做，別人想做還得 fork 出去。

HeatWave 宣傳語怎么說來著？“The only MySQL with vector”。翻譯過來：想玩向量？請(qǐng)上 OCI 買我們的云。

遲到多年的優(yōu)化器

9.7 倒是有一條實(shí)質(zhì)性更新：Hypergraph Optimizer 下放社區(qū)版了（WL ）。

MySQL 傳統(tǒng)優(yōu)化器只能做左深樹 JOIN 枚舉，表一多就靠貪心啟發(fā)式剪枝，容易選爛計(jì)劃。新的 Hypergraph 優(yōu)化器基于 DPhyp 算法支持 bushy tree，用動(dòng)態(tài)規(guī)劃做 JOIN 排序，理論上能找到更優(yōu)的執(zhí)行計(jì)劃。

聽起來不錯(cuò)。但——這東西 2021 年就有了，在 Enterprise 和 HeatWave 里捂了五年才放出來；放出來默認(rèn)還是關(guān)的，得手動(dòng) SET optimizer_switch='hypergraph_optimizer=on'；開了之后不支持除 STRAIGHT_JOIN 之外的任何 hint，也不支持 TRADITIONAL 和 JSON 格式的 EXPLAIN。優(yōu)化器抽風(fēng)了怎么辦？沒有手段干預(yù)，生產(chǎn)環(huán)境裸奔。

PostgreSQL 的標(biāo)準(zhǔn)規(guī)劃器很早就支持動(dòng)態(tài)規(guī)劃 JOIN 枚舉 + bushy plan，表多了自動(dòng)切 GEQO 遺傳算法，二十多年生產(chǎn)錘煉下來穩(wěn)如老狗。恭喜 MySQL，2026 年終于讓社區(qū)用戶摸到了這扇門 —— 有了，但還默認(rèn)關(guān)著。

其他更新逐條看

外鍵終于搬家了。 MySQL 的外鍵一直在 InnoDB 引擎內(nèi)部實(shí)現(xiàn)，級(jí)聯(lián)操作不能正確記錄 binlog，主從復(fù)制在外鍵級(jí)聯(lián)場(chǎng)景下數(shù)據(jù)一致性不保證。這個(gè)缺陷存在了二十多年，9.6 才把外鍵上移到 SQL 層修掉（WL ）。當(dāng)年阿里開發(fā)規(guī)約寫“不得使用外鍵”，也許說到底就是因?yàn)?MySQL 的外鍵本來就是個(gè)笑話。

JSON Duality Views DML 下放社區(qū)版（WL ）。這功能 9.4 才有，之前增刪改要買 Enterprise——左手做功能，右手收門票，Oracle 的傳統(tǒng)才藝，頗為喜感。類似的功能 PG 十幾年前就有了。

PBKDF2 認(rèn)證增強(qiáng)（WL ）。PostgreSQL 2017 年就用 SCRAM-SHA-256 做默認(rèn)認(rèn)證了，晚了九年。五個(gè) Enterprise 組件下放社區(qū)——復(fù)制監(jiān)控、流控統(tǒng)計(jì)之類的運(yùn)維組件，本來就不該鎖在付費(fèi)版里。日期函數(shù)行為修正（WL ）——2026 年了還在修 TIMEDIFF、DAYNAME 的 corner case。Clone Plugin 跨 LTS 克隆——8.0 EOL 在即，升級(jí)得 8.0 → 8.4 → 9.7 三級(jí)跳，不能跳級(jí)。

OpenSSL 升到 3.5.0，zlib 升到 1.3.2——依賴庫(kù)升級(jí)也寫進(jìn) Release Note。

這就是三年七個(gè) 創(chuàng)新版本 攢出來的 LTS 答卷。

換個(gè)方向看看 PG

說完了 MySQL 9.7，換個(gè)方向看看正在高歌猛進(jìn)的 PostgreSQL。

去年的 PG 18 幾乎把牙膏管擠爆了，今年 PG 19 已經(jīng) feature freeze，新功能改進(jìn)更是讓人目不暇接。但比內(nèi)核更精彩的是擴(kuò)展生態(tài)。還是拿向量來說——MySQL 那邊連 DISTANCE() 都鎖在 HeatWave 里三年紋絲不動(dòng)。PG 這邊呢？

不僅有 pgvector 這個(gè)事實(shí)標(biāo)準(zhǔn)：HNSW + IVFFlat、六種距離度量、多種向量類型、AVX-512 硬件加速；甚至連擴(kuò)展的擴(kuò)展都出現(xiàn)了——pgvectorscale 基于 DiskANN 做流式優(yōu)化，有 VectorChord（vchord）用 RaBitQ 量化壓縮把成本打到地板。同一個(gè)向量搜索，PG 生態(tài)卷到飛起，在精度、性能、成本、規(guī)模各個(gè)維度把這件事做到了極致。MySQL 那邊？Oracle 還在捂著 DISTANCE() 當(dāng)寶貝。

而像這樣的擴(kuò)展，PG 生態(tài)里有多少？光我自己在 Pigsty 和 PGEXT.CLOUD[1] 上收錄的能直接用的擴(kuò)展就超過 500 個(gè)：PostGIS 做地理空間、TimescaleDB 做時(shí)序、Citus 做分布式、pg_duckdb 做分析、pg_search 做全文檢索，……

這正是 PG 連續(xù)吃到三代浪潮紅利的底層密碼：極致的可擴(kuò)展性。在傳統(tǒng)軟件時(shí)代，PostGIS 吃下了企業(yè) GIS 時(shí)代，JSONB 在移動(dòng)互聯(lián)網(wǎng)完成對(duì) MySQL 的反超，pgvector 在 AI 時(shí)代干翻一條專用向量數(shù)據(jù)庫(kù)賽道。三輪浪潮，PG 輪輪接住，MySQL 輪輪錯(cuò)過。一次是偶然，兩次是巧合，三次就是必然了。

Docker Hub 上的數(shù)據(jù)已經(jīng)很說明問題：PostgreSQL 的官方鏡像周下載量幾乎是 MySQL 的四倍。開發(fā)者在用腳投票。

MySQL 為什么會(huì)變成這樣？

反觀 MySQL，當(dāng)年的當(dāng)紅炸子雞、互聯(lián)網(wǎng)時(shí)代的寵兒，怎么就淪落至此？

除了架構(gòu)先進(jìn)性的差距，我認(rèn)為最大的問題在于：MySQL 并不是真正意義上的開源。

代碼是 GPL 公開的沒錯(cuò)。但“開源”這個(gè)詞有兩層含義：代碼公開是一層，社區(qū)才是最重要的那一層。PG 的核心開發(fā)者來自幾十家公司和獨(dú)立貢獻(xiàn)者，沒有任何一家能一家獨(dú)大。你在這個(gè)生態(tài)里的投入不會(huì)被某個(gè)“主人”一紙公告收回。

MySQL 呢？方向 Oracle 說了算。什么放社區(qū)版，什么鎖 Enterprise，什么只在 HeatWave 上用——都是 Oracle 的決定。

去年的“GitHub 停更”事件就很說明問題。2025 年下半年，mysql/mysql-server 倉(cāng)庫(kù)的 commit 數(shù)斷崖式下跌，連續(xù)幾個(gè)月近乎“歸零”。不是 MySQL 不開發(fā)了——是 Oracle 在搞封閉開發(fā)，外面只能看到一個(gè)黑盒子。你想?yún)⑴c？對(duì)不起，Pull Request 提了也石沉大海，公開的 Bug Tracker 都不是內(nèi)部真正使用的那個(gè)。

與此同時(shí)，2025 年 9 月有報(bào)道稱 Oracle 大規(guī)模裁撤 MySQL 工程團(tuán)隊(duì)，Percona 創(chuàng)始人 Peter Zaitsev 估計(jì)六七成的工程人員已經(jīng)離開。500 多名開發(fā)者聯(lián)名呼吁 Oracle 考慮建立一個(gè)廠商中立的 MySQL 基金會(huì)——Oracle 拒絕了。后來 Oracle 說“我們有新的工程領(lǐng)導(dǎo)層，2026 年會(huì)有新氣象”。9.7 大概就是這個(gè)“新氣象”的第一份答卷。大家也看到了——就這？

白嫖導(dǎo)致敝帚自珍，敝帚自珍加劇白嫖——這個(gè)死循環(huán)在 Percona CEO 寫的 里寫得很清楚了。AWS 做了 Aurora，阿里做了 PolarDB-MySQL/X，騰訊做了 TDSQL-M，大家用 MySQL 內(nèi)核競(jìng)爭(zhēng)但沒人回饋上游。Oracle 被白嫖就把好東西鎖起來。鎖起來，社區(qū)更不愿貢獻(xiàn)。MariaDB 早早 fork 走了，Percona 跳過所有 Innovation Release，VillageSQL fork 做向量，國(guó)內(nèi)的 TiDB / OceanBase 也都只是協(xié)議兼容，來分 MySQL 的蛋糕。

一個(gè)本可以百花齊放的生態(tài)，被它的主人抽干了活力，鎖住了可能性。

PostgreSQL 的故事恰好是反面。沒有主人，只有社區(qū)。沒有鎖定，只有開放。沒有一家公司能決定 PG 的命運(yùn)，所以每一家公司都愿意在上面押注。上千個(gè)擴(kuò)展、百花齊放的生態(tài)、連續(xù)三輪浪潮的準(zhǔn)確卡位——這不是某個(gè)天才架構(gòu)師的遠(yuǎn)見，而是開放治理和極致可擴(kuò)展性自然演化出來的結(jié)果。

再見，MySQL

MySQL 誕生于 1995 年，在 LAMP 的黃金時(shí)代里幾乎是“數(shù)據(jù)庫(kù)”的代名詞。那些年，每一個(gè)學(xué) PHP 的少年、每一個(gè)搭 WordPress 的站長(zhǎng)、每一個(gè)寫 Ruby on Rails 的極客，默認(rèn)的第一個(gè)數(shù)據(jù)庫(kù)就是 MySQL。它簡(jiǎn)單、快速、到處都有——那是一個(gè)好東西不需要復(fù)雜的時(shí)代，MySQL 恰好是最簡(jiǎn)單的那一個(gè)。

但時(shí)代變了。數(shù)據(jù)類型變了，工作負(fù)載變了，開發(fā)者的預(yù)期變了。GIS 來了，MySQL 接不住；JSON 來了，MySQL 慢半拍；向量來了，MySQL 干脆連函數(shù)都鎖在云里。不是 MySQL 變差了——是世界對(duì)數(shù)據(jù)庫(kù)的要求變高了，而 Oracle 把 MySQL 進(jìn)化的可能性一點(diǎn)一點(diǎn)封死了。

三十年河?xùn)|，三十年河西。天下沒有不散的宴席。

2026 年 2 月，F(xiàn)OSDEM 和 MySQL Community Summit 剛結(jié)束，Percona 聯(lián)合創(chuàng)始人 Vadim Tkachenko 牽頭發(fā)表了一封致 Oracle 的公開信。248 位來自 Percona、MariaDB、PlanetScale、DigitalOcean、Pinterest 等公司的數(shù)據(jù)庫(kù)工程師和架構(gòu)師聯(lián)名簽署。Tkachenko 在接受采訪時(shí)說了一句話：

"We see MySQL kind of becoming a legacy technology, and we think if we don't take some steps, it risks becoming irrelevant."

——我們眼看著 MySQL 正在變成一種遺留技術(shù)，如果不采取行動(dòng)，它有變得無關(guān)緊要的風(fēng)險(xiǎn)。

Legacy technology。遺留技術(shù)。這個(gè)詞從 MySQL 最大的第三方生態(tài)公司創(chuàng)始人嘴里說出來，分量不言自明。當(dāng) MySQL 最忠實(shí)的守護(hù)者們開始用“l(fā)egacy technology”來稱呼它的時(shí)候，屬于 MySQL 的時(shí)代就真的過去了。這不是詛咒，這是安魂。就像 Delphi 之于編程語言，就像 Solaris 之于操作系統(tǒng)——曾經(jīng)輝煌過的技術(shù)，在時(shí)代轉(zhuǎn)彎的時(shí)候沒有跟上，就會(huì)被無聲地留在身后。

一代人終將老去，但總有人正年輕。

數(shù)據(jù)庫(kù)老司機(jī)

點(diǎn)一個(gè)關(guān)注 ??，精彩不迷路

對(duì) PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群（搜pigsty-cc）