MySQL 9.7 LTS，何至于此

兩年前 MySQL 9.0 發布的時候，我寫了一篇《》當時 Oracle 敲鑼打鼓搞了個創新版，加個 VECTOR 數據類型就敢吹成 “AI 時代的 MySQL”。

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

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

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

鍋里還是那碗冷飯。

花架子依舊的向量能力

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

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

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

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

遲到多年的優化器

9.7 倒是有一條實質性更新：Hypergraph Optimizer 下放社區版了（WL ）。

MySQL 傳統優化器只能做左深樹 JOIN 枚舉，表一多就靠貪心啟發式剪枝，容易選爛計劃。新的 Hypergraph 優化器基于 DPhyp 算法支持 bushy tree，用動態規劃做 JOIN 排序，理論上能找到更優的執行計劃。

聽起來不錯。但——這東西 2021 年就有了，在 Enterprise 和 HeatWave 里捂了五年才放出來；放出來默認還是關的，得手動 SET optimizer_switch='hypergraph_optimizer=on'；開了之后不支持除 STRAIGHT_JOIN 之外的任何 hint，也不支持 TRADITIONAL 和 JSON 格式的 EXPLAIN。優化器抽風了怎么辦？沒有手段干預，生產環境裸奔。

PostgreSQL 的標準規劃器很早就支持動態規劃 JOIN 枚舉 + bushy plan，表多了自動切 GEQO 遺傳算法，二十多年生產錘煉下來穩如老狗。恭喜 MySQL，2026 年終于讓社區用戶摸到了這扇門 —— 有了，但還默認關著。

其他更新逐條看

外鍵終于搬家了。 MySQL 的外鍵一直在 InnoDB 引擎內部實現，級聯操作不能正確記錄 binlog，主從復制在外鍵級聯場景下數據一致性不保證。這個缺陷存在了二十多年，9.6 才把外鍵上移到 SQL 層修掉（WL ）。當年阿里開發規約寫“不得使用外鍵”，也許說到底就是因為 MySQL 的外鍵本來就是個笑話。

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

PBKDF2 認證增強（WL ）。PostgreSQL 2017 年就用 SCRAM-SHA-256 做默認認證了，晚了九年。五個 Enterprise 組件下放社區——復制監控、流控統計之類的運維組件，本來就不該鎖在付費版里。日期函數行為修正（WL ）——2026 年了還在修 TIMEDIFF、DAYNAME 的 corner case。Clone Plugin 跨 LTS 克隆——8.0 EOL 在即，升級得 8.0 → 8.4 → 9.7 三級跳，不能跳級。

OpenSSL 升到 3.5.0，zlib 升到 1.3.2——依賴庫升級也寫進 Release Note。

這就是三年七個 創新版本 攢出來的 LTS 答卷。

換個方向看看 PG

說完了 MySQL 9.7，換個方向看看正在高歌猛進的 PostgreSQL。

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

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

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

這正是 PG 連續吃到三代浪潮紅利的底層密碼：極致的可擴展性。在傳統軟件時代，PostGIS 吃下了企業 GIS 時代，JSONB 在移動互聯網完成對 MySQL 的反超，pgvector 在 AI 時代干翻一條專用向量數據庫賽道。三輪浪潮，PG 輪輪接住，MySQL 輪輪錯過。一次是偶然，兩次是巧合，三次就是必然了。

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

MySQL 為什么會變成這樣？

反觀 MySQL，當年的當紅炸子雞、互聯網時代的寵兒，怎么就淪落至此？

除了架構先進性的差距，我認為最大的問題在于：MySQL 并不是真正意義上的開源。

代碼是 GPL 公開的沒錯。但“開源”這個詞有兩層含義：代碼公開是一層，社區才是最重要的那一層。PG 的核心開發者來自幾十家公司和獨立貢獻者，沒有任何一家能一家獨大。你在這個生態里的投入不會被某個“主人”一紙公告收回。

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

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

與此同時，2025 年 9 月有報道稱 Oracle 大規模裁撤 MySQL 工程團隊，Percona 創始人 Peter Zaitsev 估計六七成的工程人員已經離開。500 多名開發者聯名呼吁 Oracle 考慮建立一個廠商中立的 MySQL 基金會——Oracle 拒絕了。后來 Oracle 說“我們有新的工程領導層，2026 年會有新氣象”。9.7 大概就是這個“新氣象”的第一份答卷。大家也看到了——就這？

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

一個本可以百花齊放的生態，被它的主人抽干了活力，鎖住了可能性。

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

再見，MySQL

MySQL 誕生于 1995 年，在 LAMP 的黃金時代里幾乎是“數據庫”的代名詞。那些年，每一個學 PHP 的少年、每一個搭 WordPress 的站長、每一個寫 Ruby on Rails 的極客，默認的第一個數據庫就是 MySQL。它簡單、快速、到處都有——那是一個好東西不需要復雜的時代，MySQL 恰好是最簡單的那一個。

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

三十年河東，三十年河西。天下沒有不散的宴席。

2026 年 2 月，FOSDEM 和 MySQL Community Summit 剛結束，Percona 聯合創始人 Vadim Tkachenko 牽頭發表了一封致 Oracle 的公開信。248 位來自 Percona、MariaDB、PlanetScale、DigitalOcean、Pinterest 等公司的數據庫工程師和架構師聯名簽署。Tkachenko 在接受采訪時說了一句話：

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

——我們眼看著 MySQL 正在變成一種遺留技術，如果不采取行動，它有變得無關緊要的風險。

Legacy technology。遺留技術。這個詞從 MySQL 最大的第三方生態公司創始人嘴里說出來，分量不言自明。當 MySQL 最忠實的守護者們開始用“legacy technology”來稱呼它的時候，屬于 MySQL 的時代就真的過去了。這不是詛咒，這是安魂。就像 Delphi 之于編程語言，就像 Solaris 之于操作系統——曾經輝煌過的技術，在時代轉彎的時候沒有跟上，就會被無聲地留在身后。

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

數據庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

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