MySQL AI三义辨析：Serverless MySQL作为AI Agent统一后端

关键要点

• “MySQL AI” 有三层含义。只有一种，即 MySQL 作为代理后端，才是架构决策。
• 代理需要持久化六种数据类型。其中五种需要事务和精确过滤；嵌入向量是新增的一种。
• 社区版和商业版 MySQL 可以存储向量，但不能进行比较。DISTANCE() 是 HeatWave 和 MySQL AI 独有的功能。
• 一个兼容 MySQL 的后端同时存储记忆、工具输出和嵌入向量，可以消除分离架构中的同步错误。

MySQL AI，从对应用团队最重要的意义上讲，指的是兼容 MySQL 的基础设施，它将代理记忆、工具输出、嵌入向量和持久化应用状态保存在一个后端中，并在同一查询中提供向量搜索和 SQL。用于 AI 代理的无服务器 MySQL 就是这种后端，以自动扩展服务的形式交付，而不是需要你调整大小、分片和照料的集群。

搜索“MySQL AI”得到的结果并不相同。有些描述了为你编写和调优 SQL 的工具，而另一些则描述了 MySQL 产品中内置的 AI 功能。还有一些甚至描述了 MySQL 位于 AI 应用之下，作为其系统记录。这三种情况都是真实存在的，并且它们导致不同的架构决策。本博客涵盖第三种情况，因为它是决定你的代理在 10,000 个并发会话下是否仍然可用的关键。

MySQL AI 究竟意味着什么？

“MySQL AI” 目前具有三种不同的含义，搜索结果将三者混杂在一起。首先厘清它们可以避免你评估错误的对象。

常见的三种含义：

• AI 辅助 SQL 工作流。 副驾和模式感知助手生成查询、解释执行计划并建议索引。AI 位于数据库旁边，而非内部。
• MySQL 产品中内置的 AI 功能。 MySQL 9.0 在 2024 年新增了原生 VECTOR 数据类型。2025 年 9 月，Oracle 宣布推出 MySQL AI，这是企业版的一组功能集，添加了向量引擎、文档生成式 AI、AutoML 和自然语言转 SQL 等功能。这些是数据库功能，与特定版本和部署模式绑定。
• MySQL 作为 AI 应用和代理的后端。 数据库存储对话历史、工具调用结果、工作流检查点、嵌入向量以及代理读写的数据。AI 运行在数据库之上，并依赖它来确保正确性和持久性。

第一种是生产力问题，你的 IDE 大多已经解决了。第二种，如果你是 Oracle 企业客户，则很重要，但它并不能指导你设计代理后端。第三种是你做出的一次性架构决策，需要长期维护。

为什么 MySQL AI 从查询辅助转向应用架构

两年前，关于 MySQL 和 AI 的对话大多围绕如何更快生成 SQL。现在则关注数据库需要存储什么才能让代理正常运行。这种转变将要求从便利性转移到正确性。

从 SQL 副驾到 AI 代理

副驾是无状态的。它读取你的模式，发出查询，然后忘记所有内容。而代理则相反：它会在多少次对话、会话和天数的过程中积累状态。它记得用户上周询问了什么，已经调用了哪些工具，五步工作流中的哪一步失败了，以及它检索了什么来支持回答。每一个都是写操作，每一次都必须经受住进程重启。

为何状态和记忆现在变得重要

故障模式是特定的。当代理记忆保存在缓存中，工具输出保存在对象存储中，嵌入向量保存在向量数据库中，而业务记录保存在 MySQL 中时，你现在就有了四个可能不一致的系统。用户更新其账户，代理从向量存储中检索到过期的嵌入向量，然后自信地根据两小时前的数据回答。这称为检索漂移。将持久化状态整合到一个事务性后端可以消除这一类错误，这就是为什么ai 代理记忆数据库的问题现在在架构评审中很早就出现，而不是在发布之后。

AI 代理需要 MySQL 后端提供什么

代理后端并不是单一的工作负载。它大致包含六种，具有不同的访问模式但有相互重叠的一致性要求。下表映射了代理持久化的内容以及为什么关系存储承担了大部分工作。

表 1：大多数代理后端持久化的六种数据类型，其中五种仍然需要关系型保证。

记忆和对话历史

记忆读取几乎从来不是纯语义的。一个现实的回忆查询会要求最相似的先前轮次对于这个用户，在这个工作区，且未过期。其中一个是向量操作，其他三个是索引列上的精确谓词。将它们分散在两个系统中意味着从一个系统拉取候选集，然后在应用代码中进行过滤。

工具输出和工作流状态

工具调用花费金钱和时间。缓存网络搜索、丰富 API 或代码执行的结果可以让代理在失败后重试工作流而无需再次支付。该缓存需要精确匹配查找、TTL 和事务更新，以及它所属于的工作流行。

可搜索知识和嵌入向量

嵌入是这里唯一真正新增的数据类型。它们需要向量列、距离函数和避免扫描每一行的索引。它们不需要的是单独的数据库，前提是您已经运行的数据库能够为它们建立索引。

MySQL 向量搜索在技术栈中的位置

向量搜索将文本、图像或文档存储为嵌入（固定长度的浮点数数组），然后使用余弦距离等距离函数查找与查询嵌入最接近的嵌入。近似最近邻索引使该搜索成为亚线性搜索，而不是全表扫描。

用于 RAG 和搜索的语义检索

这是检索增强生成（RAG）的检索部分：嵌入问题，找到最接近的块，将它们作为上下文传递给模型。相同的机制为语义产品搜索、去重、推荐和长期智能体记忆提供支持。各引擎的支持情况各不相同，在承诺之前值得检查。MySQL 9.x 原生存储向量，但未在 InnoDB 中提供 HNSW 索引，因此大规模相似性搜索退化为穷举比较。分布式引擎采用不同的方法，如这篇关于 mysql 向量搜索 的解析所述。

为什么向量搜索在关系型上下文中效果更好

向量检索对于大多数 AI 功能是必要的，但对于几乎所有功能来说都还不够。重要的查询结合了这两部分。在 TiDB（它扩展了 MySQL 语法，增加了 VECTOR(D) 类型和向量函数）中，针对单个租户的智能体记忆查找如下所示：

一条查询，一次往返，一个一致性模型。在将其复制到生产环境之前有两点实用说明：TiDB 的 HNSW 索引需要 TiFlash 副本，并且必须在创建时声明其距离函数；高选择性的 WHERE 子句可能会使优化器选择扫描而非向量索引。请使用真实的过滤基数进行测试，而不是无过滤的基准测试。结合这两种路径的设计权衡在关于 TiDB serverless 向量搜索 的演练中有所覆盖。

为什么 Serverless 数据库架构对 MySQL AI 很重要

这里的 Serverless 指的是一组特定的运维属性：无需节点规格选择、无需容量规划、由请求量驱动扩展、计费与消耗相关而非预置硬件。这些属性恰好与 AI 工作负载的实际行为非常吻合。

更快的实验和更低的设置摩擦

大多数 AI 功能起初是原型，可能三个月后就不存在了。在知道想法是否可行之前，配置集群、调整实例规模和配置副本，是将时间花在基础设施而不是产品上。一个在一分钟内即可访问的数据库会改变您的团队愿意尝试的内容。

更适合突发性 AI 工作负载

智能体流量是突发的，这一点与 CRUD 流量不同。一个用户触发一个工作流，该工作流扇出到 200 次工具调用和 5,000 次嵌入查找，然后系统空闲一小时。预置容量迫使您在为峰值付费和峰值期间失败之间做出选择。对于峰值不可预测的工作负载，具有规模归零下限的请求驱动扩展消除了这一选择。

从原型到生产的更清晰路径

原型数据库的真正风险不是成本，而是重写。如果快速选项与生产数据库的方言不同，那么成功意味着迁移。从原型到生产都保持 MySQL 语法，意味着即使部署层级发生变化，模式、ORM、驱动程序和查询也能在过渡中存活。

如何评估用于 AI 智能体的 Serverless MySQL

在比较选项时，将此部分用作清单。每个项目都对应着有人在生产中已经遇到的失败。

• MySQL 协议兼容性。 您现有的驱动程序、ORM 和迁移工具能否无需更改地工作？
• 原生向量存储和 ANN 索引。 是否有真正的索引，还是相似性搜索随着行数增长而退化为全表扫描？
• 相似性旁边有精确过滤。 一条查询能否应用租户、时间和状态谓词 并 按距离排序？
• 事务保证。 智能体能否原子地写入工具输出并推进检查点？
• 多租户隔离。 隔离是查询级属性，还是每个租户需要自己的数据库？
• 运维开销。 谁处理分片、故障转移、备份和升级？
• 扩展路径。 在 100 倍数据量时会发生什么：配置更改、层级更改还是迁移？

在团队通常选择的三种架构中运行这些标准：

表 2：用于智能体后端的三种架构，在启动后而非原型期间显现的维度上进行比较。

拆分架构是一个可辩护的默认选择：专门的向量数据库具有通用引擎无法匹敌的成熟索引和调整旋钮。如果您的工作负载以检索为主且关系型足迹很小，那么这种专业化值得集成成本。当嵌入是智能体依赖的六种数据类型之一，而其中五种需要事务时，计算方式就会改变。有关专业选项的调查，请参阅这篇关于 机器学习的向量搜索 的概述。

TiDB 在 MySQL AI 架构中的位置

TiDB是一个分布式SQL数据库，支持MySQL协议并原生存储向量，因此它位于该表格的第三行。不要把代理记忆视为需要集成的独立系统，而是将其视为您已经查询的数据库中的另一个表。

MySQL兼容性，不放弃现代AI功能

TiDB兼容MySQL协议，因此现有的驱动程序、连接字符串和大多数应用程序SQL无需修改即可工作。在此基础上，它增加了VECTOR(D)列类型、包括VEC_COSINE_DISTANCE和VEC_L2_DISTANCE的距离函数，以及HNSW向量索引。向量类型适用于TiDB Cloud Starter、Essential和Dedicated，以及TiDB Self-Managed v8.4.0或更高版本，建议使用v8.5.0或更高版本。

统一SQL、向量搜索和可扩展状态

实际的好处是前面显示的查询：相似性排名和精确谓词一起解决，针对推进工作流的同一事务写入的数据。TiKV中的行存储处理事务路径，而TiFlash中的列存储服务分析和向量工作负载，因此评估仪表板和代理流量不会争夺资源。这就是为什么TiDB显示为用于AI代理的数据库，而不仅仅是MySQL的替代品。

面向快速发展的工程团队的无服务器MySQL

TiDB Cloud Starter是自动扩展的入门层，于2025年8月从TiDB Cloud Serverless更名。它包括每个实例的免费月度配额，每个组织最多五个免费实例，足以让每个工程师或每个拉取请求拥有独立的数据库。AI代理平台Manus在TiDB上运行超过100万个代理租户，并在大约两周内完成了迁移。

在可超越原型的后端上运行MySQL AI

MySQL AI不再只是关于编写更好的SQL的问题。对于构建代理的团队，这关乎记忆、工具输出、嵌入和工作流状态所在的位置，以及在负载下它们是否保持一致。您在第一周选择的答案就是您在第二年仍在运行的答案。

如果您正在评估用于AI的无服务器MySQL工作负载，最快的测试是对您自己的数据运行上述查询，并检查一个后端是否保存了您的代理所需的所有六种数据类型。

Brian Foster是TiDB的全球内容总监。在技术内容、出版和编辑领导方面拥有超过20年的经验，他专注于分布式SQL、云基础设施和软件开发领域的故事讲述和内容创作。

本博客由TiDB解决方案工程师Ravish Patel进行了技术准确性审查。

本博客参考了TiDB产品文档中关于向量数据类型、向量搜索索引和TiDB Cloud层级限制的内容；Oracle MySQL文档和MySQL 9.x的发布说明； VECTOR 支持及2025年9月的MySQL AI公告；以及内部公司的客户架构审查。最后更新于2026年9月4日。

MySQL AI常见问题

MySQL可以用作AI代理的数据库吗？

可以。对话历史、工具输出、工作流检查点和审计跟踪都需要有序读取、精确过滤和事务，这是普通的关系型工作。经典MySQL部署中的差距在于大规模向量检索，因为MySQL 9.x存储向量但在InnoDB中没有提供ANN索引。

MySQL支持用于RAG的向量搜索吗？

MySQL 9.0及更高版本包含原生VECTOR数据类型和距离函数，足以存储嵌入并运行相似性查询。生产级RAG依赖于索引的可用性：如果没有近似最近邻索引，相似性搜索将比较每一行，并随着语料库的增长而性能下降。

MySQL AI和AI for SQL有什么区别？

AI for SQL是指帮助人类编写和调优查询的工具：副驾驶、自然语言转SQL、索引顾问。从架构上讲，MySQL AI意味着数据库本身通过存储代理读写所需的嵌入、记忆和状态来服务AI应用。

为什么在AI工作负载中使用无服务器数据库？

AI流量是突发性的，且往往是实验性的。无服务器部署消除了容量规划，可以在几秒内启动，因此原型易于放弃，在扇出高峰期间随请求量扩展，空闲时成本很低。

团队何时应该选择MySQL兼容的AI后端而不是分离栈？

当嵌入是代理依赖的几种数据类型之一、检索必须遵守租户或新鲜度等精确过滤条件、以及小团队无法消化两个数据库时，选择统一后端。当工作负载以检索为主且语料库规模非常大时，选择分离栈。

文章用于AI代理的无服务器MySQL：在一个后端中存储记忆、工具输出和可搜索状态首次出现在TiDB上。