MySQL 26.10.0 正式发布：健康监控进社区版，REST 服务直接内置

一句话看懂：社区版补上了自带的健康监控，REST 服务不用再单独跑 Router，WebAuthn 也向社区版开放了。

2026 年 10 月 20 日，MySQL 26.10.0 正式发布。这是一次 Innovation 创新版本更新，同一批还发布了 9.7.4 LTS 和 8.4.13 LTS 两个长期支持分支。

对 DBA 来说，这次的重点不是又多了几个参数，而是数据库自带能力的边界往外扩了一圈：监控、REST 接入、认证方式和 JSON 数据访问控制，都在往社区版靠。

先看重点

• 健康监控 Health Monitor 进入 Community Edition
• MySQL REST Service 作为服务器组件内置，不再必须单独运行 MySQL Router
• WebAuthn 认证插件向社区版开放
• JSON 关系双视图新增更细的更新控制注解

一、健康监控进入社区版

这是本次发布最值得 DBA 关注的变化。

此前 Health Monitor 主要面向 MySQL HeatWave。从 26.10.0 开始，Community Edition 也支持该组件，通过 Performance Schema 获取 CPU、内存、文件系统和 MySQL 进程等资源信息，并提供历史数据和磁盘空间预测能力。

这意味着社区版用户可以直接用数据库自身的机制观察资源压力、评估磁盘容量风险，减少对外部监控工具的单一依赖。

需要说清楚三点：

• 首版 Linux 支持完整指标集，macOS 只支持部分基础指标，Windows 暂不支持。
• 它是运维能力的补充，不能替代专业监控平台。
• 历史数据的保留周期和采集开销，要在上线前实测。

运维视角：如果你的 MySQL 一直靠外部探针采集，这次可以先在测试环境对比一遍数据口径，再决定是否把容量预测这类能力收回到数据库侧。

二、REST Service 集成进服务器

26.10.0 把 MySQL REST Service 作为服务器组件提供，可以直接通过 HTTPS 暴露服务接口，不再必须单独运行 MySQL Router 来承载。

管理员可以配置 TLS 证书、工作线程数、最大连接数和请求体大小等参数，并通过 SQL 函数管理服务状态。

对开发者来说，部分 REST 应用的部署架构可以简化；对运维来说，新的攻击面也随之出现。以下三件事必须同步纳入管理：

• HTTPS 端口是否对外开放，防火墙策略是否明确。
• 证书的签发、续期和轮换流程是否覆盖这个新入口。
• 连接数、请求体大小和访问控制是否设置了上限。

运维视角：服务内置不等于安全边界内置。原本由 Router 承担的限流和访问控制，现在要有人接手。

三、WebAuthn 认证向社区版开放

本次更新把 authentication_webauthn 插件提供给 Community Edition，支持基于 FIDO 设备的认证，可用于构建多因素认证或无密码登录方案。

对希望加强数据库身份认证、减少传统密码依赖的企业，这是一条可评估的路径。

但要注意，部署前至少确认四件事：

• 客户端和驱动是否支持该认证方式。
• 认证设备的发放、挂失和补办流程。
• 账号锁定与应急恢复通道。
• 自动化任务和监控采集使用的账号如何改造。

不要把它理解成装上就能全链路无密码。数据库认证只是整条链路中的一环。

四、JSON 关系双视图的控制更细

针对 JSON Relational Duality Views，本次新增 CHECK、NO CHECK、UPDATE 和 NO UPDATE 注解，可以更精细地控制 ETag 校验范围，以及字段是否允许通过视图更新。

这带来的直接好处是更新规则更明确，并发修改场景下的控制复杂度下降，也为面向 API 的数据访问设计提供了更多选择。

运维视角：权限和更新规则下沉到视图层之后，变更评审要覆盖视图定义，不能只看表权限。

五、还有哪些变化

除上述四项，26.10.0 还包含复制、Group Replication、安全和构建兼容性等方面的修复，并引入了与四段式版本标识相关的能力。

对生产环境来说，这类底层修复往往比新功能更重要，尤其是复制链路和构建兼容性，建议在测试环境单独验证。

六、升级前的检查清单

1. 完成全量备份，并验证恢复流程可用。
2. 盘点现有插件，重点确认认证插件和第三方插件的兼容性。
3. 检查主从复制与组复制状态，记录当前延迟基线。
4. 核对监控采集方式，评估 Health Monitor 与现有平台的指标口径差异。
5. 如果启用 REST Service，新增端口、证书和访问控制一并纳入变更。
6. 梳理使用 WebAuthn 的账号，确认客户端和应急通道。
7. 审查 JSON 关系双视图的注解变更，补充并发更新测试。
8. 在测试环境用真实业务 SQL 跑一轮回归，再安排生产窗口。

七、该选哪个分支

• 8.4 LTS：偏保守，适合对稳定性要求最高的核心库。
• 9.7 LTS：较新的长期支持分支，适合希望兼顾新特性与支持周期的团队。
• 26.10 Innovation：适合想提前验证新能力、且能接受较短支持周期的场景。

Innovation 版本的价值在于提前试水，不建议在没有验证的情况下直接替换核心生产库。

写在最后

MySQL 26.10.0 的方向很明确：把运维监控、REST 接入、身份认证和 JSON 访问控制这些原本需要外部组件或企业版能力的事情，往数据库自身收。

能力下沉是好事，但责任也随之下沉。监控口径、证书、端口、认证设备和视图权限，最后都要落到运维的日常清单里。

本文信息核验截至 2026 年 10 月 25 日。官方 APT 仓库中对应版本为 26.10.0-1ubuntu22.04，9.7 LTS 与 8.4 LTS 分别为 9.7.4 和 8.4.13。具体行为与限制请以 MySQL 官方发布说明为准。