MySQL官宣最新版26.10：内置REST服务，数据库要干掉后端吗？

(Updated: )
AI

聊具体操作之前，得先解答很多开发者心中的第一个疑问：我们日常在生产环境用的明明是 MySQL 5.7 或者 MySQL 8.0，怎么版本号突然跳到了“26.10”？

这源于 MySQL 近年来在版本策略上的重大调整。在 8.4 LTS 和 9.7 LTS 之后，官方全面推行了创新版（Innovation）与长期支持版（LTS）的双轨模式。更关键的是，从 2026 年开始，创新版不再沿用以往的单一数字顺延，而是改用了基于日历的版本命名规则（Calendar Versioning，即 YY.M.P，年份.月份.补丁号）。2026 年 7 月发布的 26.7.0 是第一个日历化命名的创新版本，而这次测试所用的 26.10.0，正是紧随其后的 2026 年 10 月季度更新。

就在 2026 年 10 月 21 日，Oracle 宣布 MySQL REST Service（简称 MRS）的 Server Component 随 MySQL 26.10 正式 GA。

其实 MRS 这个概念在之前的 MySQL 生态里就已经出现过，但当时它的定位是 MySQL Router 外部代理的一个模块。客户端发出的 HTTP 流量首先打到 Router，Router 解析后再通过标准的 MySQL 网络协议转发给后端的数据库实例。这种架构下，中间不仅多了一次网络跳转，团队还得单独维护 Router 这一套外部运行环境。

而 26.10 带来的改变在于，MRS 被做成了一个标准的 Server Component，直接加载进 mysqld 内部。

客户端通过 HTTPS 调用 MySQL Server 进程内的 MRS 组件，访问预先配置的表、视图或存储过程

这意味着数据库自身直接监听 HTTPS 端口，在进程内部完成 HTTP 请求解析与数据读写，把外部代理的通信消耗完全抹平了。不过，装上组件并不等于数据库里的所有表都会被自动对外暴露，具体的资源路径、读写权限以及字段映射，必须经过显式配置。

上手配置与避坑

测试准备了一台运行 Docker 的机器，拉取官方 mysql:26.10.0 镜像。容器对外映射了两个端口：宿主机的 13306 端口用于常规的 MySQL 客户端连接，33443 端口则留给新增的 HTTPS 服务。

测试用到的数据表叫 http_demo.todos，结构很简单：

1
2
3
4
5
CREATE TABLE http_demo.todos (
    id INT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(200) NOT NULL,
    done TINYINT NOT NULL DEFAULT 0
);

准备好基础表之后，需要通过一组特定的配置命令把数据表映射成 REST API。这里涉及的完整指令如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CONFIGURE REST METADATA;

CREATE REST SERVICE /demo;
CREATE REST SCHEMA /db ON SERVICE /demo FROM http_demo;

CREATE REST VIEW /todos ON SERVICE /demo SCHEMA /db
    AS http_demo.todos @INSERT @UPDATE @DELETE {
        id: id @SORTABLE,
        title: title,
        done: done
    }
    AUTHENTICATION NOT REQUIRED;

ALTER REST SERVICE /demo PUBLISHED;

这段配置把 /demo 设为服务根路径，/db 作为 Schema，/todos 作为具体的资源端点。花括号中指定了字段映射规则，@INSERT @UPDATE @DELETE 开放了写操作权限，AUTHENTICATION NOT REQUIRED 则是为了本地试验方便设置为免登录。

看着逻辑很顺，但实际动手时，很容易在三个细节上踩坑。

第一个坑是语法解析陷阱。上面这些以 CREATE REST ... 开头的语句，并不是标准的 SQL 语法，而是 MySQL Shell（mysqlsh）的专属扩展指令。如果习惯性把这些脚本扔给 Navicat、DBeaver，或者直接在传统的 mysql 命令行客户端里执行，会直接抛出语法解析错误。这很容易让人误以为镜像版本有问题或者文档写错了。

第二个坑是组件的异步就绪与未发布状态。安装核心组件使用的依然是标准 SQL：

1
2
INSTALL COMPONENT 'file://component_mysql_rest_service';
SHOW GLOBAL STATUS LIKE 'mysql_rest_service.state';

执行完 INSTALL COMPONENT，并不代表 HTTPS 端口已经可用，因为组件的初始化是异步完成的。必须观察全局状态，确认 mysql_rest_service.state 的值变成 READY 之后才能正常接收请求。更关键的是，前面的配置语句中有一行 ALTER REST SERVICE /demo PUBLISHED;，这步如果遗漏，即便组件显示就绪，所有对外请求也都会被拒绝访问。

第三个坑是参数编码的细微差异。在客户端调用条件查询时，很多编程语言的类库（比如 Python 的默认 urlencode）会习惯把空格编码为加号 +。当把包含空格的 JSON 过滤条件以这种方式传过去时，MRS 会直接报 HTTP 400，提示 FilterObject 不是合法的 JSON 字符串。只有严格使用标准的 %20 进行百分比编码，条件查询才能被正确识别。

用HTTP增删改查

避开上述配置问题后，就可以暂时把 SQL 客户端放在一边，完全使用 HTTP 请求来操作数据。

定义好的完整接口地址是 https://127.0.0.1:33443/demo/db/todos。由于本地测试使用的是自签名证书，curl 命令加上 -k 参数跳过证书校验。

先试着新增一条记录，直接通过 POST 提交 JSON 数据：

1
2
3
4
5
API='https://127.0.0.1:33443/demo/db/todos'

curl -ki -X POST "$API" \
  -H 'Content-Type: application/json' \
  -d '{"id":1001,"title":"Test HTTP API","done":0}'

服务端立即返回了 HTTP 200。切回传统的 SQL 命令行执行 SELECT * FROM http_demo.todos;，刚插入的数据已经端端正正躺在表里。

接下来更新数据，把刚才创建的这条待办标记为已完成：

1
2
3
curl -ki -X PUT "$API/1001" \
  -H 'Content-Type: application/json' \
  -d '{"id":1001,"title":"HTTP update works","done":1}'

再次回到终端查表，done 字段已经更新为 1。

读取数据时的体验也非常贴近标准后端接口。执行一次无参的 GET 请求：

1
curl -ki "$API"

返回的内容不仅包含数据数组，还带了完整的分页元数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "items": [
    {
      "id": 1001,
      "title": "HTTP update works",
      "done": 1
    }
  ],
  "limit": 25,
  "offset": 0,
  "hasMore": false,
  "count": 1
}

接口自带了 limit、offset 和 hasMore，基本不需要调用方额外处理分页封装。

如果需要条件过滤，可以通过 q 参数传递 JSON 格式的查询条件。例如只检索已经完成的条目，或者按照 ID 进行删除：

1
2
3
4
5
6
# 查询已完成项
curl -ki -G "$API" --data-urlencode 'q={"done":1}'

# 删除刚才创建的记录
curl -ki -G -X DELETE "$API" \
  --data-urlencode 'q={"id":1001}'

删除执行完毕后，HTTP 返回成功。在 SQL 里重新查询该主键，记录计数清零；再次通过 HTTP 主键路径访问，服务端准确响应 HTTP 404。

从增、删、改、查到分页与条件过滤，整个流程完全闭环。有一点需要注意，这轮操作中新增成功的响应状态码返回的是 HTTP 200，在实际编写前端调用逻辑时，不要将成功判定写死为仅接受 201。

能不能干掉后端

很多人会把它和 GraphQL 这类快速出接口的方案放在一起看。两者的初衷很像：都是为了减少中间层胶水代码，让前端更直接地拿到结构化数据。

但区别也很直接：GraphQL 依然需要维护一个独立服务去写 Schema 和 Resolver，胜在能跨数据源灵活聚合、按需裁切字段；而 MySQL 的内置 REST 则是更极端的减法，直接把应用层干掉，由数据库在进程内把表和视图映射成标准端点。

它的目的不是淘汰后端，而是把那些原本需要专门搭个 FastAPI 或 GraphQL 服务才能搞定的纯数据中转，直接压缩成几条数据库配置。

工程落地建议

如果你手头正好有内部看板、数据大屏、后台小工具，或者需要极速交付的原型 Demo，以前可能要专门起一个 FastAPI 或 Node 服务给前端吐数据，现在完全可以用 MySQL 26.10 跑个容器直接顶上，省掉整套后端项目的工程初始化与部署流水线。

但只要遇到多数据源拼装、复杂的业务流转或精细化裁切，依然应该回到专业的 API 网关或 GraphQL。

在最简单的数据中转场景下做彻底的减法，把机械代码省到极致，就是它目前最舒服的落地姿势。