MySQL 8.0 到期，和它同时发生的另外两件事

2026-09-24 Aryee 0

2026 年 MySQL 这边有三件事，分开看都是发布说明里的一行，叠在一起才看得出方向。下面的时间线取自 Oracle 的支持政策页与各版本的发行说明；这类页面上的具体到日的口径在不同表格之间偶有几天出入，动手排期前以你合同里那份 EOL 表为准，别拿本文当依据落日期。

事一：8.0 的支持期真的过了

Oracle 的公告口径是：MySQL 8.0 在 2026 年 4 月转入 Sustaining Support（支持政策页与周期数据页给的到日值不完全一致，这一格要你自己去核）。

这一档的含义是：不再有新特性、不再有安全修复、不再有关键补丁，只有合同性质的有限维持。所以「我们内网隔离，晚点升没关系」这个理由，从这天起不成立了——不是因为会被打，而是因为下一个 CVE 不会有人给你补丁。

同一批时间线，把节奏标清楚（取自各版本的发行说明；到日只留我确认过的那几个）：

时间	发布
2026 年 4 月这一批	8.4.9、9.7.0 LTS
2026-06-30	8.4.11
2026-07-28	9.7.2、26.7.0

要注意的一层关系是：9.7.0 这一档 LTS 与 8.0 转入维持支持落在同一个季度。旧 LTS 退场、新 LTS 就位，这个衔接是刻意排出来的——所以"等下一档再看"这个选项，从这天起变成"你已经站在新一档的窗口里"。

事二：版本号换了一套记法

26.7.0 的主版本号从 9 跳到了 26，2026 年 7 月 28 日。公开讨论把它解释成切到日历版本号（YY.M.P，26 年 7 月这一档），我没能从官方页面上找到把这句话写明的位置，所以这一条只按事实用：版本号形态确实变了，四位数主版本已经出现。此前的 9.0 到 9.6 全部是 Innovation 档，9.7 是 LTS。

把这套记法读通，就明白 Oracle 的意图：

LTS 大约两年一档：8.4 在 2024 年 4 月底，9.7 在 2026 年 4 月这一批；按五年维持支持往后推，9.7 的支持期落在 2034 年 4 月那一档（确切到日的值以你的订阅支持表为准）。
Innovation 按季度出，用来分发新特性，不承诺向前兼容。
版本号里带上年月，"这是哪一次季度补丁"变得一眼可见——不用再从 9.x 的递增去反推时间。

对使用方的直接影响：别把 Innovation 版本装进生产。过去有人按「数字大就是新稳定版」的习惯去升 9.x，那批版本之间不保证兼容性。以后看到 26.x 这类四位数主版本，也要先确认它是哪一档再决定。

事三：向量检索这件事，社区版拿不到

这条是我今年看到误传最多的。9.x 起手册里确实有 VECTOR 类型和 DISTANCE()、STRING_TO_VECTOR()、VECTOR_DIM()、VECTOR_TO_STRING() 这一组函数，于是大量文章写成「MySQL 支持向量检索了」。

9.7 手册里那句限制说明被同时跳过了，原文大意是：DISTANCE() 只对 OCI 上的 HeatWave 用户和 MySQL AI 提供，不包含在 MySQL 商业版和社区版发行中。

也就是说类型和序列化函数在，算距离的那一步不在。没有距离函数，向量列对普通部署的意义接近零——你还是得把数据捞到应用层自己算。

这不是说 MySQL 不该被用来存向量（把 embedding 当普通列存、在应用侧算相似度，很多场景够用），而是它不构成「我们有了向量数据库」这个结论。做选型时如果有人拿这一条论证 MySQL 可以替代专业向量库，让他把手册那一页贴出来。

8.0 → 9.7：会真正咬到升级的清单

版本号看着是 8 到 9，但该走两跳：8.0 → 8.4 LTS → 9.7 LTS。理由是 8.4 这一档集中了会砸到现网的默认值与语法变更，而且这些变更在 8.4 上暴露、在 9.7 上还会再叠一层。

8.4 的「主要变化」页面里，我认为是硬性检查项的有这些：

一、mysql_native_password 默认不再启用。 这是最常见的升级后第一声报错。老版本客户端、老连接池、以及手写账号表时用了这个插件的，连不上时报的是认证错误而不是版本错误，很容易被误判成网络问题。

二、旧的复制语法被移除。 CHANGE MASTER TO、SHOW SLAVE STATUS、RESET MASTER、START/STOP SLAVE 这一整套要换成 REPLICATION/REPLICA 词形。运维脚本和监控采集里几乎一定还有这些语句，它们不在应用代码里，代码扫描扫不到——必须单独把脚本仓库过一遍。

三、几个工具直接没了：mysql_upgrade、mysqlpump、keyring_file 插件。前者换成 mysqld 就地升级，后者换成 keyring component 体系，迁移路径不一样，别按旧习惯找同名命令。

四、InnoDB 默认值批量调整：innodb_change_buffering 默认改成 none、自适应哈希索引（AHI）默认关闭，I/O 能力与 redo 相关的几项默认值也一起调过（具体到每一项被抬到哪，以你要升的那一版的"changed defaults"页为准，别按二手清单设参数）。这几项在 SSD 上是合理默认，但它们会改变你的性能画像基线——升级后的对比要和新默认比，不能和三年前的经验值比。

五、新增权限项（如 FLUSH_PRIVILEGES、SET_ANY_DEFINER）与 tagged GTIDs。前者会影响存储过程/视图的 definer 相关操作，后者是升级前需要确认复制拓扑的地方。

顺便纠正一个流传很广的说法：降序索引不是 8.4 才实现的，MySQL 8.0 就已经支持。这类「新版本才有」的印象很多来自二手清单，落到操作上之前建议回一次官方 nutshell 页。

超图优化器值得单独验，但别抱默认期待

9.7 把超图优化器（Hypergraph Optimizer）和 Group Replication 的可观测性能力下放到了社区版——这是这一档对选型最有实际影响的一条，因为它挪动了「社区版 vs 商业版」的边界。

但「进入社区版」不等于「默认启用」，也不等于「对你的负载更快」。验证成本很低：

从生产抓一段慢查询日志，挑 join 表数 ≥ 3、扫描行数大的那十几条。
在预发实例上分别在新旧优化器下跑，比对执行计划与耗时。
结论只看这一批查询。绝大多数点查两边没差别，测不出来也没有意义。

点查为主、复杂 join 少的系统，切过去收益可能接近零；报表和多表关联密集的库，差距可能一眼看出来。这是一个需要按负载重新测的开关，不是一个可以按版本默认值接受的设置。

一条可执行的顺序

步骤	动作	什么情况下不许继续
0	备份 + 恢复演练	只验了备份文件存在，没验恢复能启动
1	SQL 与脚本兼容性扫描（应用 + 运维脚本 + 监控）	复制相关的旧语句还没改完
2	账号认证插件先迁到 `caching_sha2_password`	还有账号停在 native password 上
3	升到 8.4，业务不动	观察期内慢查询数量明显高于基线
4	统计信息重算 + 关键表执行计划复核	核心查询计划变了但没人解释得清为什么
5	升到 9.7 LTS	第 3、4 步还没稳定
6	单独立项评估超图优化器	第 5 步刚完成