编程 MySQL 版本号跳到 26.10：升级必须先落在 9.7，AUTO_INCREMENT 也开始跳号

2026-11-13 20:01:33

MySQL 26.7 / 26.10 改用 CalVer：版本号不再说明是不是 LTS，升级路径要看 compatibility lineage

MySQL 26.7 于 2026 年 7 月 28 日发布，MySQL 26.10 于 2026 年 10 月 20 日发布。从 MySQL 9.7 之后，版本号的命名方式本身发生了改变。

版本号改为日历版本（CalVer）

MySQL 9.7 LTS 是最后一条使用递增版本号的发布线，之后迁移到 YY.M.P 形式的日历版本：YY 是发布年份的后两位，M 是发布月份，P 是补丁（维护）发布号，从 0 开始。也就是说 MySQL 26.7.0 表示「2026 年 7 月的发布」。手册明确写着「MySQL 26.7.0, representing the July 2026 release, is the first valid calendar-versioned MySQL release」，即这是第一个合法的日历版本。如果是 LTS 发布，整个支持生命周期内 YY.M 固定不变，只有 P 递增。

从版本号无法判断是否 LTS

以前看 8.4、9.7 这样的编号就能判断是 LTS 还是 Innovation，日历版本不行。手册的说法是：「A calendar version does not determine whether a release is an Innovation or LTS release. Release maturity remains an explicit property of each release.」发布成熟度成了与版本号独立的属性。选版本时不能靠编号推断，需要单独确认该 release 的定位。

LTS 与 Innovation 本身的性质没有变化。LTS 在发布线内不做功能删除，支持期为 Premier 5 年加 Extended 3 年；Innovation 只支持到下一个 Innovation 发布为止，并且前提是会带入弃用功能删除这类行为变更。

compatibility lineage 与升级路径

日历版本只表示「什么时候构建的」，不表示能升级到哪。因此引入了 compatibility lineage（兼容性谱系）这个新概念来判定升级路径。一条 lineage 由「某个 LTS 发布 + 它之前的那批 Innovation 发布」构成，LTS 之后出现的第一个 Innovation 发布开启新的 lineage。规则如下：

Innovation 发布可以升级到同一 lineage 内更新的发布（包括关闭该 lineage 的那个 LTS）
Innovation 发布不能跨越 lineage 边界
LTS 发布可以升级到自身发布线内，或紧邻的下一个 lineage
LTS 发布不能跳过 lineage

为了做这项判定，服务端会把 lineage 元数据持久化到数据字典中。

从旧版本迁移方面，手册写明「只有 MySQL 9.7.x LTS 才能进入第一个日历版本 lineage」。用 9.7 以外版本的，必须先升到 9.7 系。降级依旧严格，只允许在同一 LTS YY.M 发布线内做补丁降级；Innovation 发布降级需要逻辑 dump 和 restore。

这是真正会打断现有运维的地方：不能跨 lineage 直接跳、不能跳号，且必须先在 9.7 落脚。

MySQL 26.7 的新特性

InnoDB AUTO_INCREMENT 计数器预分配

AUTO_INCREMENT 计数器的持久化改为批量化，由新的全局动态系统变量 innodb_autoinc_preallocate 控制。

mysql> SELECT @@innodb_autoinc_preallocate;
+------------------------------+
| @@innodb_autoinc_preallocate |
+------------------------------+
| 50 |
+------------------------------+

默认一次预留 50 个值，目的是减少元数据更新次数。代价是服务器异常停机时，已预留但未使用的值会被跳过。依赖编号连续性的应用要注意。正常关闭时实际计数器值会被持久化，不会产生空洞。想避免跳号就把该变量设为 0，关闭额外的预分配。

Change Stream Applier（CSA）

26.7 新增的复制应用引擎，作为传统多线程 applier（MTA）之外的选项，按 channel 逐个 opt-in。它把「应用」和「提交顺序控制」分离来提高并行度，每个 channel 支持 1～1024 个 worker。

传统 MTA 的设计是一个 worker 从头到尾绑在一个事务上：应用早就结束了，还要等提交顺序，线程一直被占着，别的 worker 空闲也拿不到活。CSA 把应用和提交拆开，应用完的 worker 立刻回到池里取下一个任务，提交顺序由另一个队列保证。

mysql> CHANGE REPLICATION SOURCE TO
    -> APPLIER_VERSION = 2,
    -> APPLIER_WORKER_COUNT = 8,
    -> APPLIER_EVENT_MEMORY_LIMIT = 1073741824
    -> FOR CHANNEL 'channel_name';
Query OK, 0 rows affected (0.01 sec)

APPLIER_VERSION 为 1 是 MTA（新 channel 的默认值），2 是 CSA。在已有 channel 上修改前，需要先停掉 SQL 线程。

限制不少：CSA 以行格式复制和 GTID 为前提，statement 或 MIXED 格式的 binlog、基于 file position 的 channel、延迟复制（SOURCE_DELAY）、sql_replica_skip_counter 等场景都不能用。

其它变更

InnoDB undo 表空间变为 crash-safe。不再生成 undo_space_number_trunc.log 标记文件，进行中的状态记录在 undo 表空间文件头部。
此前仅限企业版的 Thread Pool 插件在社区版也可用，thread_pool_max_unused_threads 默认值从 2 改为 32。
Group Replication 中 group_replication_communication_stack 的默认值从 XCOM 改为 MYSQL，并且该变量本身已被弃用。
保留字变更：CUBE、EXTERNAL、QUALIFY、TABLESAMPLE 成为新保留字。把它们当标识符用的，升级前要检查。
服务端变量 replica_parallel_type 与 group_replication_allow_local_lower_version_join 已移除（26.10 的移除列表同样包含这两项）。
mysql_version.h 新增 MYSQL_PREVIOUS_LTS_VERSION / MYSQL_PREVIOUS_LTS_VERSION_ID（例："9.7.0" / 90700），C 库侧可以识别旧 LTS。

MySQL 26.10 的新特性

四段式版本标识符

版本号增加了 UPDATE 要素，变成 MAJOR.MINOR.PATCH.UPDATE 四段，用于区分同一补丁线上单独分发的更新。

mysql> SELECT VERSION(), VERSION_WITH_UPDATE();

VERSION()、version 系统变量、mysqld --version 仍返回原来的三段式兼容版本。要取四段值，用 VERSION_WITH_UPDATE() 函数、version_with_update 系统变量或 mysqld --version-with-update。UPDATE 为 0 时也始终显示。另外 mysql_upgrade_history 审计文件的 update_history 数组会记录精确的发布迁移。

JSON Duality View 的更新控制更细

JSON_DUALITY_OBJECT() 支持在表级和列级指定 CHECK / NO CHECK，在列级指定 UPDATE / NO UPDATE。

JSON_DUALITY_OBJECT(
  ...
  WITH (UPDATE, CHECK)
  "status": status WITH (NO UPDATE, NO CHECK)
)

CHECK 控制参与 ETag 计算的列，UPDATE 控制能否经视图修改的字段。列的设置继承表级设置，只有显式覆盖时才使用单独的值。表级默认是 CHECK，主键列不能指定 UPDATE。实际生效的设置可通过 JSON_DUALITY_VIEW_COLUMNS 的 ALLOW_CHECK 与 ALLOW_UPDATE 查看。

在复制环境中，源端用新语法发 DDL 之前，需要先升级副本。

MySQL REST Service 变成服务器组件

MySQL REST Service（MRS）成为服务器组件 component_mysql_rest_service，不必再单独跑 MySQL Router 进程就能提供 HTTPS 端点。

mysql> INSTALL COMPONENT 'file://component_mysql_rest_service';
Query OK, 0 rows affected (0.05 sec)

mysql> SHOW GLOBAL STATUS LIKE 'mysql_rest_service.state';

端口由 mysql_rest_service.http_port 指定，默认 33443。启动、停止、重启通过 mysql_rest_service_start() 这类 UDF 完成，都需要 MYSQL_REST_SERVICE_ADMIN 权限。

其它变更

Health Monitor 在社区版可用。Linux 上提供全部指标，macOS 只有内存、文件系统、CPU 的基础指标，Windows 不支持。
新增 authentication_webauthn 插件，可配置基于 FIDO 的多因素认证和无密码登录。
EXPLAIN 输出包含选中的分区：树形格式显示分区名，JSON v2 格式新增 partitions 数组。
optimizer_switch 和 optimizer_trace 必须精确指定 flag 名。以前 o、of 之类的缩写能通过，现在会报 ER_WRONG_VALUE_FOR_VAR。

收尾

会打断现有运维的是这几类：升级必须先落到 9.7.x LTS 才能进入日历版本 lineage，跨越 lineage 或跳号都不行；CUBE、EXTERNAL、QUALIFY、TABLESAMPLE 成为保留字；replica_parallel_type、group_replication_allow_local_lower_version_join 被移除；optimizer_switch / optimizer_trace 的缩写不再接受。

26.7 中值得留意的还有 innodb_autoinc_preallocate 的预分配行为、TLS 的后量子加密支持，以及新增的 Change Stream Applier；26.10 的重点是四段式版本标识符、JSON Duality View 更新控制的细化，以及 MySQL REST Service 的组件化。CSA 需要按 channel 显式开启，innodb_autoinc_preallocate 可以设为 0，JSON Duality View 新语法、MRS 组件、Health Monitor、WebAuthn 都是可选启用，不改变既有部署的默认行为。

参考链接

What Is New in MySQL 26.7: https://dev.mysql.com/doc/refman/26.7/en/mysql-nutshell.html
What Is New in MySQL 26.10: https://dev.mysql.com/doc/refman/26.10/en/mysql-nutshell.html
Changes in MySQL 26.7.0: https://dev.mysql.com/doc/relnotes/mysql/26.10/en/news-26-7-0.html
MySQL Releases: Innovation and LTS: https://dev.mysql.com/doc/refman/26.10/en/mysql-releases.html
原文（gihyo.jp 第283回）: https://gihyo.jp/article/2026/11/mysql-rcn0283

复制全文生成海报 MySQL 运维数据库升级

编程 MySQL 版本号跳到 26.10：升级必须先落在 9.7，AUTO_INCREMENT 也开始跳号

MySQL 26.7 / 26.10 改用 CalVer：版本号不再说明是不是 LTS，升级路径要看 compatibility lineage

版本号改为日历版本（CalVer）

从版本号无法判断是否 LTS

compatibility lineage 与升级路径

MySQL 26.7 的新特性

InnoDB AUTO_INCREMENT 计数器预分配

Change Stream Applier（CSA）

其它变更

MySQL 26.10 的新特性

四段式版本标识符

JSON Duality View 的更新控制更细

MySQL REST Service 变成服务器组件

其它变更

收尾

参考链接

推荐文章