MySQL 26.7 EA来了：版本号一夜跳到26，社区版正在发生变化

前段时间 MySQL 社区在讨论的版本号问题，终于落地了。

7 月 3 日，MySQL 26.7.0 的 Early Access 版本已上线 MySQL Labs。这是第一个采用全新日历版本号（Calendar Versioning）的 MySQL 版本，版本号从 9.7.0 一跃变成了 26.7.0，跨度之大，让很多从业者第一反应是：“这假新闻吧，MySQL 哪来的 v26？”

并不是。MySQL 没有跳过十几个大版本，而是做了一件更重要的事：彻底推翻用了二十多年的版本号体系，换了一套全新的命名规则。

01. 版本号从"数数字"变成"看日历"

以前的 MySQL 版本号是纯顺序的：5.7 → 8.0 → 8.4 → 9.7。直观是直观，但有个让人头疼的问题，你看一眼版本号，根本不知道它是什么时候发布的，也不清楚支持周期还剩多久。

Oracle 在 2026 年 6 月 16 日正式宣布，MySQL 将全面转向日历版本（Calendar Versioning），格式为YY.M，也就是"年份后两位.月份"。比如 26.7 就是 2026 年 7 月发布，26.10 是 2026 年 10 月，27.1 是 2027 年 1 月。

这种命名方式其实也是有好处的，看到版本号，立刻就能知道发布时间，也就能大致估算支持周期还有多长。也不用再维护一张"版本号→发布日期"的对照表。

当你在看 Oracle 数据库版本号的时候，有没有跟我一样其实也有关注日历部分，比如：Oracle RU 19.31.0.0.20260421。

02. Innovation 和 LTS 两条线并行

MySQL 的发布轨道还是两条线：

Innovation 版本（创新版）：每季度发布一次，面向想要快速跟进新功能的用户。版本号跟着日历走，比如 26.7.0 → 26.10.0 → 27.1.0。

LTS 版本（长期支持版）：面向追求稳定性的生产环境。一旦被指定为 LTS，YY.M 前缀在整个支持周期内保持不变。待 28.4.0 成为 LTS 后，后续更新就是 28.4.1、28.4.2、28.4.3…… 版本号本身就在告诉你：这是 2028 年 4 月那版的延续。

目前两个现有 LTS 版本：MySQL 8.4 和 MySQL 9.7，将继续按原有模式维护。

03. 我对比了 26.7.0 和 9.7.0，发现了这些变化

为了提前搞清楚 26.7.0 到底带来了哪些创新特性，我下载了 26.7.0 和 9.7.0 两个版本的源码包做了全量对比。

1/ 版本号基础设施

26.7.0 在源码层面引入了完整的日历版本验证框架。cmake/mysql_version.cmake里新增了验证宏，明确规定 9.8 到 26.6 之间的所有版本号都是非法的。也就是说，9.7.0 是传统语义版本的终点，之后直接跳到 26.7.0，没有中间站。

版本文件中新增了MYSQL_PREVIOUS_LTS_VERSION=9.7.0字段，建立了从 9.7.0 到 26.7.0 的升级谱系。代码层面会强制执行版本升级路径检查，防止跳过中间版本。

2/ 后量子密码学（PQC）支持

MySQL 26.7.0 引入了完整的后量子密码学 TLS 支持，新增了 12 个与 PQC 相关的系统变量，覆盖主通道、管理接口、X 协议和复制通道。

启动时会看到一条新警告：

TLS channel ‘mysql_main’ is not configured to require post-quantum key exchange algorithms; future TLS sessions may use a non-post-quantum key exchange algorithm because force_pqc is disabled

这说明 MySQL 已经在为量子计算时代的安全威胁做准备。配合 OpenSSL 3.5+，可以直接启用 PQC 密钥交换算法。支持的算法组按优先级排列包括 X25519MLKEM768、secp384r1MLKEM1024 等混合 PQC 方案，以及纯 ML-KEM 方案，同时也保留了传统 ECDH 作为回退。

3/ Change Stream Applier

这是 MySQL 26.7.0 里最值得关注的功能 additions。CSA 是一套全新的复制应用器实现，目标是改善并行应用行为，给未来的复制架构打基础。

CSA 的执行模型和现有 MTA 不同：它把应用进度和提交进度分开，后面的独立事务在前面事务等依赖时可以继续执行，中继日志事件的读取也更接近执行时间。设计上还引入了每个通道的独立控制参数：APPLIER_VERSION、APPLIER_WORKER_COUNT、APPLIER_EVENT_MEMORY_LIMIT。

使用方式是在复制通道上设APPLIER_VERSION = 2。现有的多线程应用器（APPLIER_VERSION = 1）仍然保留，所以你可以逐步迁移，而不用一刀切换。

不过需要注意，这个版本里的 CSA 主要面向基于行的 GTID 复制。语句格式或混合格式的 binlog、文件名/偏移量定位的通道、延迟应用模式等，暂时还不支持。

4/ InnoDB 底层重构

MySQL 26.7.0 对 InnoDB 的恢复和元数据基础设施做了一系列改进，包括 Redo log 接口抽象、表空间接口、MVCC 和 ReadView 接口、独立的 Redo log 重放，以及把持久化表元数据和 checkpoint 解耦。

这些变化对用户是无感知的。MVCC 行为和事务可见性与之前完全一致。但底层代码结构的改善意味着以后维护和扩展会更安全，出问题的概率更低。

5/ 线程池插件下放社区版

很多社区版用户等了很久的变化。MySQL 26.7.0 把线程池插件（Thread Pool Plugin）从企业版下放到了社区版。

高并发场景下，大量连接会创建过多的调度开销和 InnoDB 内部资源争用。线程池通过管理语句执行线程，让服务器并行度维持在一个主机可以承受的范围，减少延迟波动。社区版用户现在有了一个经过验证的官方方案，不用再依赖第三方补丁。

6/ 升级检查进度报告

做过大规模升级的人都有这样的体会，升级前的兼容性检查在复杂架构上可能跑很久，你盯着终端不知道它是在正常工作还是卡死了。MySQL 26.7.0 给这个过程加了进度报告，升级准备工作至少变得可观测了。

04. Oracle 对 MySQL 社区的投入，这次不一样

技术变化之外，更值得关注的可能是 Oracle 在社区治理上的一系列动作。"Oracle 会不会慢慢把 MySQL 闭源"这个话题在开发者圈子里讨论了十几年，但从 2025 年下半年到 2026 年的这一系列动作来看，风向确实在变。

1/ 技术指导委员会成立

2026 年 6 月 25 日，Oracle 宣布成立 MySQL Steering Committee，初始成员包括 AWS、Google Cloud 和 Oracle 自己。

AWS 数据库副总裁 Ganapathy Krishnamoorthy 的表态值得注意：

“开源在社区共同塑造方向时才能繁荣。MySQL 是世界上使用最广泛的数据库之一，一个透明、包容的治理模型能让每一个依赖它的人受益。”

这个委员会不是来替代技术领导层或日常开发流程的。它的定位是战略指导和社区代表的论坛，确保重要战略讨论能从多元视角中获益。AWS 和 Google Cloud 愿意加入，本身就是一个信号。

2/ 社区治理框架成型

Oracle 发布了《MySQL 治理文档》和《MySQL 开发者指南》，定义了参与角色：

• Contributors：通过代码、测试、文档、评审参与
• Committers：有经验的贡献者，帮评审变更、维护代码质量
• Mentors：带新人
• Project Leads：为 MySQL 关键领域提供技术领导力

另外还设了专门的安全漏洞协调小组，管漏洞报告、安全评审和披露。

3/ Bug 处理透明化

Oracle 新增设了 MySQL Bug Dashboard，能看到 bug 积压的改善进展。截至 2026 年 6 月 22 日，Server 的 bug 最多，其次是 Workbench 和 Connectors。Oracle 还承诺定期公开贡献者增长、问题响应趋势等数据。

这里多说一句，MySQL Workbench 8 可能会彻底 EOL，不久的将来或推出全新的 MySQL Workbench 10。我最近在写一款轻量级数据库管理工具，初步计划可以连接多款国产数据库，造轮子是为了更好的理解轮子。

4/ 公开路线图 + GitHub 协作

MySQL 的社区路线现在以 GitHub Project 的形式公开发布，覆盖了 26.7 及后续版本的功能规划，分 AI & Cloud、Developer/DBA Experience、Extensibility/Ecosystem、Performance & Observability 几个维度。

社区公共讨论已经办了好几期，下一期是 2026 年 7 月 15 日。Contributor Summit 也在持续搞，最近那次汇集了 AWS、Google Cloud、Percona、ProxySQL、MariaDB Foundation 的人。

05. 下半年发版计划

一张表带你了解一下 MySQL 在 2026 年下半年的发版计划。

2027 年继续按季度发创新版：27.1、27.4、27.7、27.10。预计 2028 年 4 月的 28.4 会是下一个 LTS。

CPU 指的是关键补丁更新 (Critical Patch Update)：Oracle 的常规季度安全补丁更新周期。对于 MySQL 而言，CPU 补丁会通过常规的 MySQL 发布包进行推送，因此这些发布包可能包含除安全补丁之外的其他内容。对于 MySQL LTS 版本，季度更新包会包含安全补丁和错误修复，同时保持系统稳定性。

CSPU 指的是关键安全补丁更新 (Critical Security Patch Update)：Oracle 在今年新推出的一种针对特定安全问题的更新，在季度 CPU 更新之间按月发布。AI 时代，安全漏洞的发现速度较之前更快，按月推出关键补丁可以帮助客户更快的修复高危安全漏洞。

06. 老版本怎么办？

MySQL 8.0 已经结束生命周期，官方建议升级到 8.4 LTS。但现实是，相当一部分生产环境还在用 5.7，甚至有人觉得“MySQL 5.7 是最好的版本，是性能巅峰状态”。

AWS RDS MySQL 5.7 目前还在维护。Oracle 通过延长 5.7 的维护周期和明确的升级路径，给了用户过渡时间。如果继续停留在 5.7 意味着错过了从 8.0 开始的大量改进，如 JSON、窗口函数、CTE、降序索引、不可见索引，以及安全增强。

我自己做迁移项目的时候，从 5.7 到 8.0 最直观的感受是：优化器变得聪明了很多，以前要手动调的场景现在能自动处理了。当然，迁移成本是真实的，尤其是有历史包袱的系统。但一直不升级，技术债务只会越积越多。

关于作者：严少安, Oracle ACE Pro, MySQL OCP。
公众号「少安事务所」，由 严少安 主笔，专注于数据 & AI 领域技术传播。

兼容 MySQL 的国产数据库选择

除了升级到官方 MySQL 8.4/9.7 LTS 之外，国内用户还有一个重要的选项：迁移到兼容 MySQL 协议的国产数据库。这类产品在语法、协议层面与 MySQL 高度兼容，可以大幅降低迁移成本，同时满足信创合规要求。

下表是目前市面上兼容 MySQL 的几款国产数据库产品：

这几家在 MySQL 兼容性方面做得比较成熟，社区资料和迁移工具也相对丰富

写在最后

MySQL 26.7.0 的发布，将标志着这个有着 30 多年历史的数据库进入了一个新阶段。

（旁白：此处或许有物是人非的感慨，影响数据库选型的决定性因素从来都不只是技术，改版本号更不会影响选型。）

MySQL 版本号体系的根本性改变，表面上是命名规则的调整，实际上是 Oracle 对于 MySQL 社区治理加强投入的结果。

对于 MySQL 用户而言，如果你还在关注社区成长、技术迭代，26.7.0 EA 已经在 Labs 里等着你去试。

Have a nice day ~ ☕

👉 这里有得聊

欢迎关注：「少安事务所」。如果这篇文章为你带来了灵感或启发，请帮忙『点赞、转发、推荐』，感谢！ღ( ´･ᴗ･` )~