MySQL 9.7 LTS正式发布深度解析：八年支持难掩创新乏力，Oracle治理困局与PostgreSQL完胜之路
两年前 MySQL 9.0 发布之际，我曾在《MySQL 安魂九霄，PostgreSQL 驶向云外》一文中剖析过，Oracle当时大张旗鼓地推出所谓的创新版本，仅仅添加了个VECTOR数据类型就敢宣称"AI时代的数据库"。我一眼看穿：这玩意儿本质就是BLOB套了个马甲。没有距离函数，没有向量索引，除了能往列里塞一堆浮点数之外什么也干不了。之后的两年间，从9.0到9.6共推出了七个创新版本，每季度准时发布。然而Percona对这些版本连眼皮都懒得抬一下。PMM遥测数据显示，Innovation Release的市场采用率始终在1%附近挣扎，连被统计的资格都没有。这家全球最大的MySQL第三方生态公司，用无声的沉默投下了反对票。
为何现在要聚焦9.7？因为这是MySQL 9.x系列首个LTS长期支持版本：5年标准支持+3年扩展支持。此前七个Innovation Release不过季抛型过渡品，Percona不跟进，用户不敢碰，所有人都在苦等这个LTS落地。更何况MySQL 8.0将在2026年4月停止维护，存量用户必须迁移，9.7几乎成了唯一的出路。
某些公众号作者已然开始惊呼——“MySQL 9.7震撼发布！性能飙升！““让MySQL迈入AI时代！"——尽管截至2026年4月，这玩意儿连正式版都还没发布，仅是3月底放出了个早期测试二进制包。我反正下载下来体验了一番——
端上来的还是那碗隔夜饭。
中看不中用的向量功能
翻开MySQL 9.7参考手册第14.21章《向量函数》，整个向量模块既无向量索引，也无最近邻搜索能力，向量列不能作为主键、外键或唯一键，更不支持聚合函数。唯一算得上实用的Distance函数，居然还是付费专享功能。
老冯满腹疑惑，就这么个鸡肋功能，也值得Oracle藏着掖着，刻意放在商业版里膈应用户？MySQL何至于沦落至此？连自家人都看不下去。MariaDB 11.7去年底已原生支持VECTOR INDEX+HNSW算法；TiDB推出了向量索引Beta版；PlanetScale用SPANN算法自研了一套；Google Cloud SQL for MySQL基于ScaNN实现了向量索引；VillageSQL直接fork了MySQL 8.4专攻向量场景；甚至个人开发者都写出了第三方向量插件。Oracle自己不做，别人想做还得另起炉灶。
HeatWave的宣传语怎么说的来着？“唯一具备向量能力的MySQL”。翻译成人话就是：想玩向量？请去OCI买我们的云服务。
姗姗来迟的查询优化器
9.7总算拿出了一项实质性更新：Hypergraph优化器总算向社区版开放了（WL #17265）。MySQL传统优化器只能生成左深树JOIN执行计划，表一多就依赖贪心启发式剪枝，极易选出劣质方案。新的Hypergraph优化器基于DPhyp算法支持浓密树，通过动态规划寻找最优JOIN顺序，理论上能挖掘更优执行计划。
听着挺美。然鹅——这玩意儿2021年就有了，在Enterprise和HeatWave里捂了整整五年才肯放出来；放出来后默认还是关闭状态，必须手动执行SET optimizer_switch='hypergraph_optimizer=on'；开启后不支持除STRAIGHT_JOIN外的任何hint，也不兼容TRADITIONAL和JSON格式的EXPLAIN。 一旦优化器抽风，你连干预手段都没有，直接在生产环境裸奔。
PostgreSQL的标准规划器早就能通过动态规划枚举+浓密树计划处理复杂JOIN，表多了自动切换GEQO遗传算法，经过二十多年的生产环境锤炼稳如泰山。恭喜MySQL，直到2026年才让社区用户摸到这扇门的门槛——功能有了，但默认给你关着。
其余更新细数看
外键实现终于重构了。 MySQL的外键逻辑一直内嵌在InnoDB引擎中，导致级联操作无法正确写入binlog，主从复制在外键级联场景下数据一致性毫无保障。这个存在了二十多年的缺陷，直到9.6才将外键上移至SQL层修复（WL #11249）。当年阿里开发规约严禁使用外键，追根究底或许正是因为MySQL的外键本身就是个笑话。
JSON Duality Views的DML操作向社区版开放（WL #17246）。这项功能9.4才引入，此前增删改操作必须购买Enterprise版——左手开发功能，右手收门票，Oracle的传统艺能，颇具讽刺意味。类似功能PostgreSQL十几年前就已具备。
PBKDF2认证增强（WL #17160）。PostgreSQL早在2017年就将SCRAM-SHA-256作为默认认证方式，MySQL晚了整整九年。五个Enterprise组件下放社区——复制监控、流控统计这类运维工具，本就不该锁在付费版里。日期函数行为修正（WL #16895）——都2026年了还在修TIMEDIFF、DAYNAME的边界问题。Clone Plugin跨LTS克隆——8.0即将EOL，升级路径必须8.0→8.4→9.7三级跳，不允许跨版本。
OpenSSL升级至3.5.0，zlib升级至1.3.2——连依赖库版本更新都值得写进Release Note里。
这就是三年七个创新版本攒出来的LTS答卷。
反观PostgreSQL的蓬勃生态
吐槽完MySQL 9.7，不妨换个视角看看正一路高歌猛进的PostgreSQL。
去年发布的PG 18几乎把牙膏挤爆，今年PG 19已冻结特性，新功能令人目不暇接。但比内核更震撼的是扩展生态。还是向量搜索——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的反超，AI时代pgvector干翻一众专用向量数据库。三轮浪潮，PG次次接住，MySQL次次错过。一次是偶然，两次是巧合，三次就是必然。
Docker Hub上的数据已然说明一切：PostgreSQL官方镜像的周下载量近乎MySQL的四倍。开发者正在用脚投票做出选择。
MySQL衰落根源探析：Oracle治理之痛
MySQL为何会沦落到这般田地？昔日的当红炸子鸡、互联网时代的宠儿，怎么就一步步走向衰落？除了架构本身的落后，我认为根源在于：MySQL并非真正意义上的开源项目。
代码以GPL协议公开没错。但"开源"有两层含义：代码公开是一回事，社区治理才是关键。PG的核心开发者来自几十家公司和独立贡献者，没有任何一家能独断专行。你在生态中的投入不会被某个"主人"一纸公告就收回。
MySQL呢？方向全由Oracle拍板。什么功能放社区版，什么锁在Enterprise，什么只在HeatWave独占——全是Oracle说了算。
去年的"GitHub停更"事件就很能说明问题。2025年下半年，mysql/mysql-server仓库提交数断崖式下跌，连续几个月几近"归零”。并非MySQL停止开发——而是Oracle转向封闭开发，外界只能看到黑箱。你想参与贡献？抱歉，Pull Request提进去石沉大海，公开的Bug Tracker都不是内部真正用的那个。与此同时，2025年9月传出Oracle大规模裁员MySQL工程团队的消息，Percona创始人Peter Zaitsev估计六七成工程师已离职。500多名开发者联名呼吁Oracle建立厂商中立的MySQL基金会——被拒绝了。后来Oracle声称"有了新的工程领导层，2026年会有新气象”。9.7大概就是这份"新气象"的首份答卷。大家也看到了——就这？
白嫖导致敝帚自珍，敝帚自珍加剧白嫖——Percona CEO在《Oracle最终还是杀死了MySQL！》一文中剖析得很透彻。AWS做了Aurora，阿里做了PolarDB-MySQL/X，腾讯做了TDSQL-M，各家基于MySQL内核竞争却无人回馈上游。Oracle被白嫖就把好东西锁起来。锁起来，社区更不愿贡献。MariaDB早早fork出走，Percona跳过所有Innovation Release，VillageSQL fork做向量，国内的TiDB/OceanBase也只是协议兼容来分蛋糕。一个本该百花齐放的生态，被它的主人抽干了活力，封死了可能性。
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之于操作系统——曾经辉煌的技术，在时代转弯时没跟上，就会被悄无声息地留在原地。
一代人终将老去，但总有人正年轻。
