필사 모드: MySQL 9.7 之后的版本是 26.7 — 2026 年春天，MySQL 与 MariaDB 整理发布模型的方式

• 引言 — 9.7 之后不是 9.8
• 创新版本，在下一个创新版本发布的那一刻就结束了
• MySQL 9.7 LTS —— 时隔两年的一次靠岸
• 9.7 下放给社区版的东西
• 日历式版本号 —— YY.M 告诉你的事
• MariaDB 在五周后做了同样的事
• 分歧点之一 —— 支持期限 8 年对 3 年
• 分歧点之二 —— 发布说明没指出来的默认值变更
• 那么该做什么
• 结语
• 参考资料

引言 — 9.7 之后不是 9.8

截至 2026 年 7 月，MySQL 下一个创新版本的版本号是 26.7。这不是笔误。

Oracle 于 2026 年 6 月 16 日在A More Predictable MySQL Release Model一文中宣布，将把 MySQL 的版本号切换为日历式版本号。而MySQL 26.7.0 发布说明的第一条就印证了这一点。

MySQL Server now uses calendar-based versioning for releases after the 9.7 LTS series. Version values use Year.Month.Patch (YY.M.P) format. MySQL 26.7.0 is the first such calendar-version release.

版本号从 9.7 跳到 26.7，本身只是一种记法上的变化。有意思的是，这个变化正是过去两年 MySQL 发布模型实际运转方式的结论，而更有意思的是，MariaDB 在相隔五周后做了几乎同样的事。本文会把这两条线索，对照发布说明与支持政策的原文梳理清楚。

本文聚焦于发布模型和运维层面的判断。MariaDB 的内部结构(存储引擎、Galera、分区)在MariaDB 现代架构一文里另行讨论过。

创新版本，在下一个创新版本发布的那一刻就结束了

首先要复习一下 2023 年引入的 Innovation/LTS 模型。MySQL 9.7 参考手册 1.3 节里的这句话是核心。

Innovation releases are supported until the next Innovation release.

只有一句话，但在运维层面是相当重的一条件。使用创新版本期间，你的支持期限就是「直到下一个版本发布为止」，此后要想继续获得支持，除了升级别无选择 —— 也就是说，等待补丁版本这条路是不存在的。

同一份文档这样区分 LTS。

These releases only contain necessary fixes to reduce the risks associated with changes in the database software's behavior. There are no removals within an LTS release.

而对创新版本，则是这样写的：

Apart from new features in innovation releases, behavior changes are also expected as code is refactored, deprecated functionality is removed, and when MySQL is modified to behave more in line with SQL Standards.

「deprecated functionality is removed」不是一句抽象的警告，9.0 直接证明了这一点。MySQL 9.0.0 发布说明记载，mysql_native_password 认证插件已经从服务器中移除。在 8.0 里被标记为 deprecated 的东西，到了下一个大版本就消失了 —— 还抱着旧客户端、旧连接器的组织，会在这里栽跟头。

那么实际上每个创新版本活了多久？下表把 Oracle 发布说明标题里写的 GA 日期原样搬了过来。支持结束日期，按上面的规则，就是下一行的 GA 日期。

两年里七次，几乎每季度一次。如果你在生产环境里跑的是 9.x 这条线，那就意味着每个季度都得做一次大版本升级，才能维持在支持范围内。

顺带一提，9.0.0 还多了一条注脚。发布说明顶部写着 —— "This release is no longer available for download. It was removed due to a critical issue that could stop the server from restarting following the creation of a very large number of tables (8001 or more)."。因为建表数量达到 8001 张或更多可能导致服务器无法重启的问题，9.0.0 被下架并由 9.0.1 取代。这也是创新版本这条轨道是什么样子的一个例证。

正因如此，官方手册对创新版本推荐给谁也说得很直白 —— "developers and DBAs working in fast-paced development environments with high levels of automated tests and modern continuous integration techniques for faster upgrade cycles."。也就是能够每个季度测试并推进一次大版本升级的组织。大多数组织并不属于这一类，而承认自己不属于这一类，正是用好这个模型的第一步。

MySQL 9.7 LTS —— 时隔两年的一次靠岸

MySQL 9.7.0 发布说明的 GA 日期是 2026-04-21。上一个 LTS，也就是 8.4.0，按发布说明其 GA 是 2024-04-30，所以两个 LTS 之间相隔的时间，比两年只少九天。

支持期限记录在 Oracle 的Lifetime Support Policy 文档(生效日期：2026 年 5 月 1 日)的表格里。虽然只精确到月份，但这是一手信息源。

这里最扎眼的一行是 8.0。Premier 在 2025 年 4 月结束，Extended 在 2026 年 4 月结束。Oracle 的EOL 通知页面把这一点写得很直接 —— "As of April 21, 2026, MySQL 8.0 is covered under Oracle Sustaining Support."，正是 9.7.0 LTS 发布 GA 的那一天。Sustaining Support 在 Oracle 的术语里，期限无限，但不再附带新的修复、安全通告或新认证。也就是说，从 2018 年起撑起了互联网相当一部分的 8.0，如今实质上处于停滞状态。

LTS 能带来什么，手册也写得很明确。

Functionality remains the same and data format does not change in an LTS series, therefore in-place upgrades and downgrades are possible within the LTS series.

在同一条 LTS 分支内甚至可以降级，这才是实务中选择 LTS 的真正原因。有回滚路径的升级和没有回滚路径的升级，是两种不同的工作。

9.7 下放给社区版的东西

9.7 LTS 里真正值得关注的变化，与其说是功能本身，不如说是版本边界线的移动。发布说明列出的、原本只有 Enterprise 才有、现在下放到社区版的组件如下：

• Replication Applier Metrics Component
• Group Replication Flow Control Statistics Component
• Group Replication Resource Manager Component
• Group Replication Primary Election Component
• Telemetry Component

除此之外，发布说明还写了另外两点 —— "The Hypergraph Optimizer is now available in MySQL Community Edition"，以及 JSON Duality View 的 DML(insert/update/delete)支持进入了社区版服务器。

Telemetry 下放到社区版，对运维团队来说分量不小 —— 这意味着可以用 OpenTelemetry/OTLP 输出日志、指标和链路追踪，而在此之前，社区版要把 MySQL 接入和其余技术栈相同的可观测性管道，就得单独接一个导出器。Hypergraph 优化器也是用于探索复杂连接计划的东西，值得关注。

不过方向并不是单向的。同一个版本里，Dynamic Data Masking 新加入了 Enterprise 一侧。Oracle 的9.7 发布文章把它描述为 "server-side protection of sensitive data without requiring application changes"，即把掩码策略挂在基表的列上，根据执行用户或角色的不同，返回原始值或掩码后的值。下放给社区的东西，和加进 Enterprise 的东西，就这样并存在同一个版本里。

这背后是有来龙去脉的。Percona 在 2026 年 2 月 17 日发表An Open Letter to Oracle，公开提议讨论 MySQL 的治理问题。这篇文章声称 Oracle 在 2025 年秋天把 MySQL 迁移到了 OCI 并裁减了人手，把规模写成了 "roughly 50%" —— 但这是 Percona 一方的说法，并非 Oracle 确认过的数字，所以没有理由把它直接当作事实接受。不过，同一篇文章写下的、期待 9.7 能带来的几项 —— 社区版的向量函数、默认启用的 Hypergraph 优化器、带完整 DML 的 JSON Duality、PGO 构建 —— 确实都能在 9.7 发布说明里得到确认。同样公平的是，这篇文章仍然写着还想要的东西里，"vector indexes" 还留在清单上。照 Percona 自己的说法，"verification through action, not words" 或许才是判断标准 —— 而版本边界线确实发生了移动，至少说明这不只是嘴上说说。

日历式版本号 —— YY.M 告诉你的事

回到 26.7。Oracle 6 月 16 日的发布文章把这个格式定义如下。

• YY —— 年份的末两位
• M —— 发布月份，不带前导零(1 月是 1，4 月是 4，7 月是 7，10 月是 10)

文章给出的未来节奏示例是这样的。

26.7   – July 2026 Innovation release
26.10  – October 2026 Innovation release
27.1   – January 2027 Innovation release
27.4   – April 2027 Innovation release
27.7   – July 2027 Innovation release
27.10  – October 2027 Innovation release
28.1   – January 2028 Innovation release
28.4   – April 2028 LTS release
28.7   – July 2028 Innovation release

LTS 的处理方式是这套设计的核心。被指定为 LTS 的分支，在其整个生命周期里都会保留这个 YY.M 前缀 —— 28.4.0 → 28.4.X → 28.4.Y → 28.4.Z，所以哪怕到了 2030 年看到 28.4.10，光看编号也能知道这是「2028 年 4 月开始的那条 LTS 分支」。用 Oracle 的话说 —— "This ensures an LTS line retains the identity of exactly when it started."

这里真正值得实务者留意的信息，不是记法本身，而是那份示例清单本身。清单里写的下一个 LTS 是 28.4，也就是 2028 年 4 月。既然 9.7 LTS 是 2026 年 4 月，这就是一个信号：LTS 的间隔大概又是两年。不过那份清单的标题是 "Upcoming Cadence Examples"，不是路线图承诺，所以不要把 2028 年 4 月当成合同条款来接受。即便如此，从规划的角度能读出的信息是清楚的 —— 现在停靠在 9.7 LTS，下一个靠岸点大约还要两年。

发布文章还引入了一个新的维护术语。CPU(Critical Patch Update)是 Oracle 常规的季度安全补丁周期，CSPU(Critical Security Patch Update)则是季度之间、按需发布的针对性安全更新。文章把 CSPU 明确定义为 "strictly as-needed"，并明确说明它不会带来每月一次的义务。文章同时指出，季度包并不只包含安全修复 —— LTS 里包含安全修复和 bug 修复，创新版本则在此基础上再加上新功能。

已有的分支会怎样？根据发布文章和表格，8.4 和 9.7 LTS 不受影响，会继续沿用现有的编号体系。日历式版本号从 9.7 之后的版本开始适用。

关于 26.7.0 本身，还有一点需要说准确。发布说明的标题是 "Changes in MySQL 26.7.0 (Early Access Release)"。这是 Early Access，不是 GA。第一个带上新版本号的成果并不是生产发布版，所以看到 26.7 这个数字，不该据此制定升级计划。

在兼容性方面倒是有一处照顾。26.7.0 在 mysql_version.h 里新增了 MYSQL_PREVIOUS_LTS_VERSION("9.7.0")和 MYSQL_PREVIOUS_LTS_VERSION_ID(90700)(WL #17310)。版本号从 9 跳到 26，可能会让那些单纯比较数字大小的构建脚本和连接器出错，而在头文件里明确写出上一个 LTS 版本，就是为了让人能顺着这个线索追溯版本谱系。反过来说，如果你手上有解析版本号字符串的代码，现在有理由打开来检查一下了。

MariaDB 在五周后做了同样的事

这里有意思的是，MariaDB 实质上独立运行着几乎一样的结构。

MariaDB Foundation 的 12.3 LTS 公告日期是 2026 年 5 月 29 日，比 MySQL 9.7 LTS 晚五周。公告写道 "The first GA of the 12.3 series is 12.3.2" —— 在 MariaDB 里，.2 才是第一个 GA(.0 是 preview，.1 是 RC)。

在此之前的 12.0、12.1、12.2 都是滚动发布。MariaDB 发布模型文档里的这句话，和 Oracle 的规则几乎如出一辙。

There are no patch version releases of an innovation release after GA (except for emergency releases), instead users are supposed to upgrade to the next minor innovation release. In other words, innovation releases are rolling releases, one upgrades 11.3.2→11.4.2→11.5.2→11.6.2→11.7.2

同一份文档写道 "Approximately every fourth innovation release is a long-term support (LTS) release"，而MariaDB Foundation 的维护政策写道 "A new long-term release (LTS) of MariaDB Server is announced yearly"。每季度滚动一次，每年一次 LTS。

整理一下，两大阵营的结构是这样重叠的。

MySQL    : 每季度 Innovation  -> 约每 2 年一次 LTS   (下一个 Innovation 发布即结束支持)
MariaDB  : 每季度 Rolling     -> 每年一次 LTS        (下一个 Rolling 发布即结束支持)

两个相互竞争的实现走到了同一个结论，这说明这不是营销话术，而更接近一种工程上的收敛 —— 「维护一个大型开源数据库，大概只有这一种办法」。把快车道和慢车道分开，并且不对快车道承诺长期支持。

分歧点之一 —— 支持期限 8 年对 3 年

结构相同，真正的差异才显现出来。选了 LTS 之后能撑几年，两者完全不同。

MySQL 手册这样写：

An LTS series follows the Oracle Lifetime Support Policy, which includes 5 years of premier support and 3 years of extended support.

5 + 3 = 8 年。前面 Lifetime Support 表里 9.7 那一行(Premier Apr 2031，Extended Apr 2034)，正好就是这个算法的结果。

MariaDB Foundation 的维护政策不一样。

MariaDB Community LTS binaries are released for 3 years after the GA date on mariadb.org/download

要把脚注也读完，图景才完整。脚注 2 写道 "For releases up to MariaDB 11.4, the binaries are released for 5 years after the GA date."。也就是说，社区版 LTS 二进制的支持期限，在 11.4 之前是 5 年，之后缩短为 3 年。脚注 1 又加了一层缓冲 —— "Critical and security fixes will be provided in source code releases for 2 additional years beyond Community LTS binary release period."。二进制是 3 年，但严重问题和安全修复会以源码发布的形式再多提供 2 年。如果能自己构建，实际有效期是 5 年；如果依赖发行版打包，就是 3 年。这个区别在实务中影响很大。

花钱情况就不一样了。同一份政策文档写道，Enterprise 的二进制版本提供 "an extended release option maintained and supported for 5 and 8 years, respectively, after the GA date"。

一句话总结：对只用社区版的组织来说，MySQL LTS 给的是 8 年，MariaDB LTS 给的是 3 年。「两者都是开源的 MySQL 兼容数据库」这句话所掩盖的最实在的差异，就在这里。

公平地说一句，MariaDB 的 LTS 每年都会发布，所以靠岸点本身来得更频繁。更接近于「每 8 年跨一次大的」和「每 3 年跨一次小的」之间的差别。哪一种更划算，取决于组织自身的升级肌肉。

有一点需要留意：在 MariaDB Foundation 的维护政策表里，12.3 的 GA 日期和 EOL，截至本文写作时仍然是空的 TBC。所以本文没有写出 12.3 精确的 EOL 日期。「3 年」这个数字来自政策条文本身，等日期确定之后，那张表才是一手信息源。

分歧点之二 —— 发布说明没指出来的默认值变更

12.3 LTS 公告里，标注为 "Important" 的项目正好只有一条。

In MariaDB 12.3, innodb_snapshot_isolation defaults to ON

并补充道 —— "There probably is no better moment than when we release a new LTS."

先说这是个什么功能。根据MariaDB InnoDB 系统变量文档，innodb_snapshot_isolation 是 InnoDB 内部用来检测 write/write 冲突的一个开关。打开之后，如果尝试对当前 read view 里不存在的记录加锁，就会触发 ER_CHECKREAD(错误 1020)，这个错误会像死锁一样被处理，事务随之回滚。它影响的是默认隔离级别 REPEATABLE READ。按文档的说法，这个设计是为了防止 lost update 之类的异常，拒绝对快照之后被并发事务修改过的行执行 UPDATE/DELETE。

从正确性角度看，这个方向是对的。问题在于应用程序并不知道这件事。昨天还悄无声息地成功的 UPDATE，现在会因为错误 1020 回滚，如果没有重试逻辑，就会直接以失败的形式冒出来。这正是升级 LTS 时最不想遇到的那种变化。

然而，在这一点上文档和公告出现了分歧。同一份系统变量文档把默认值写成这样：

Default Value: ON (>= MariaDB 11.6.2), OFF (<= MariaDB 11.6.1)

这说的是从 11.6.2 起就是 ON，而不是从 12.3 起。哪一边是对的，看源码就能有定论。在 storage/innobase/handler/ha_innodb.cc 里逐个分支核对这个变量的默认值参数，结果是这样的：

按 MariaDB/server 分支划分的 innodb_snapshot_isolation 默认值
  11.4  -> FALSE
  11.5  -> FALSE
  11.6  -> TRUE
  11.7  -> TRUE
  11.8  -> TRUE
  12.2  -> TRUE
  12.3  -> TRUE
  main  -> TRUE

文档是对的。默认值是在 11.6 反转的，不是在 12.3。

所以对只跟随 LTS 的人来说，实际的图景是这样的：

11.4 LTS (OFF)  ->  11.8 LTS (ON)  ->  12.3 LTS (ON)
                     ^^^ 这里已经变了

也就是说，这个变更在 11.8 LTS 就已经以生效状态发布了。而11.8 LTS 公告里一次都没有提到过 snapshot isolation。整理一下：

• 从 11.4 升到 11.8 的组织，遇到了这个行为变化，却没有在公告里被告知。
• 从 11.4 直接跳到 12.3 的组织，现在才被告知 —— 但「12.3 才变」这个说法并不准确。
• 从 11.8 升到 12.3 的组织，这一条其实根本不算变化，因为早就已经是 ON 了。

这不是想指责这篇公告 —— 哪怕来得晚，把它显眼地标出来也是对的，对从 11.4 LTS 迁移过来的人来说，这正是需要的提醒。真正的要点在别处 —— 发布说明里「这次会变」，是按作者假定的升级路径来写的，不是按你的升级路径来写的。从 LTS 跳到 LTS 跨越两级，中间滚动发布里悄悄反转的默认值，就会一次性全部到达。跳过滚动发布本身是合理的运维选择，但不代表可以连跳过区间的变更日志也一起跳过。

实务上，在 LTS 升级前，在两个版本上分别取一次 SHOW GLOBAL VARIABLES 做 diff，比读公告更靠得住。顺带一提，这个功能本身也还在打磨中。MariaDB 的 Jira 里，innodb_snapshot_isolation 打开状态下与锁等待、死锁相关的问题(MDEV-40182、MDEV-40092 等)，到 2026 年仍然带着 10.11 / 11.4 / 11.8 / 12.3 作为 fix version 挂在上面。

那么该做什么

归纳起来，判断很简单。

如果你在用 MySQL 8.0 —— 现在就是那个时刻。 Extended Support 在 2026 年 4 月已经结束，现在处于 Sustaining Support，也就是不再有新的安全修复。目的地是 8.4 LTS(Extended 到 2032 年 4 月)或者 9.7 LTS(到 2034 年 4 月)。由于 mysql_native_password 从 9.0 起被移除，8.0 → 9.7 这一跳需要先做客户端、连接器的认证方式检查。如果现在没法承担这项工作，8.4 LTS 是一个诚实的中间落脚点。

如果你在用 9.x 的创新版本 —— 升到 9.7 就停下。 从 9.0 到 9.6 全部已经结束支持。9.7 是同一谱系里的 LTS，在 LTS 分支内部，原地升级和降级都是可行的。

不要把 26.7 放上生产环境。 它是 Early Access。而日历式版本号公告暗示的下一个 LTS 是 2028 年 4 月(28.4)。现在停靠在 9.7 是正确的选择。

一定要走创新轨道吗？ 大多数情况下不需要。只有当你有足够的 CI 和人力，能每季度测试并推进一次大版本升级，并且某个新功能在业务上确实非要不可时，这条路才值得。否则留在 LTS 上，才是这套模型本来设计的正常路径。Oracle 的手册也是这么写的。

如果你在用 MariaDB —— 12.3 LTS 就是目前的靠岸点。 但不要误判支持期限。社区二进制是 3 年(比 11.4 之前的 5 年缩短了)，之后还有 2 年，只以源码发布的形式提供严重/安全修复。如果依赖发行版打包，按实际 3 年来规划更安全。而且如果你是从 11.4 及以下升上来的，一定要在预发布环境确认 innodb_snapshot_isolation 会变成 ON —— 如果应用程序对错误 1020 没有重试路径，这里就会出问题。

如果你还在 MySQL 和 MariaDB 之间犹豫 —— 本文不会给出答案。 但支持期限(社区版 8 年对 3 年)和升级频率(2 年对 1 年)在功能对比表里通常不会体现，却会实打实地反映在运维成本上，值得在看基准测试之前先算一算。

结语

版本号从 9.7 跳到 26.7，是记法上的变化，但它背后的故事不是关于记法的。

从 2024 年到 2026 年，MySQL 每个季度都发布一个创新版本，每一个版本都在下一个发布的那一刻结束支持。这两年的积累，在 2026 年 4 月 21 日汇聚成了 9.7 LTS，同一个月，8.0 降级为 Sustaining Support，一个时代就此落幕。MariaDB 在五周后，用 12.3 LTS 做了一模一样的事。两个相互竞争的实现走到同一种发布结构，不是巧合，而是收敛。

而在这之下，真正的差异依然分开。以社区版计算的支持年限，8 年对 3 年；Oracle 把版本边界线向社区一侧移动，而 MariaDB 把社区二进制的支持从 5 年缩短到 3 年；还有那些在跨越 LTS 之间悄悄抵达的默认值变更。

日历式版本号能让你光看编号就知道「这个版本是什么时候开始的」。这是一项确实有用的改进。但编号不会告诉你的东西 —— 中间移除了什么、哪些默认值被反转了 —— 依然要打开发布说明，有时还得打开源码，才能知道。就像本文为了核实 innodb_snapshot_isolation 这一个变量，就得看七个分支一样。

参考资料

• MySQL 9.7 Reference Manual 1.3 — MySQL Releases: Innovation and LTS
• Changes in MySQL 9.7.0 (2026-04-21) — 发布说明
• Changes in MySQL 26.7.0 (Early Access Release) — 日历式版本号的第一个版本
• Changes in MySQL 9.0.0 (2024-07-01) — 移除 mysql_native_password，9.0.0 下架公告
• A More Predictable MySQL Release Model: Calendar Versions, LTS, and Innovation (Oracle, 2026-06-16)
• MySQL 9.7.0 LTS Is Now Available (Oracle, 2026-04-21)
• Oracle Lifetime Support Policy — Technology Products (Effective May 1, 2026, PDF)
• MySQL Product Support EOL Announcements
• MariaDB Server 12.3 LTS Released (MariaDB Foundation, 2026-05-29)
• MariaDB Foundation — Maintenance policy
• MariaDB Release Model 文档
• MariaDB InnoDB System Variables — innodb_snapshot_isolation
• MariaDB/server — storage/innobase/handler/ha_innodb.cc(默认值核实)
• An Open Letter to Oracle: Let's Talk About MySQL's Future (Percona, 2026-02-17)
• MariaDB 现代架构 — 存储引擎与复制(相关文章)