MySQL 原生向量索引还缺什么：从 VECTOR 元数据到 InnoDB 架构边界

做知识库或商品相似推荐时，团队很容易把“数据库能存向量”和“数据库能高效做向量检索”当成一件事。MySQL 目前已经有 VECTOR 数据类型，但原生向量索引、距离函数和近似近邻检索仍处在官方架构讨论阶段；真正上线时，不能只把列类型改掉就宣称完成了向量库替换。

先把 MySQL VECTOR 的现状分清

MySQL 官方仓库的 Native Vector Index 议题，讨论目标是让向量数据拥有索引、距离计算和近似近邻搜索能力。现阶段更准确的说法是：VECTOR 可以成为表的一列，但社区版并没有因此自动获得完整的相似度查询能力。你可以先把它理解为“数据库知道这是一种向量值”，而不是“优化器已经知道如何按距离找最近的几十行”。

CREATE TABLE knowledge_item (
  item_id BIGINT PRIMARY KEY,
  body TEXT NOT NULL,
  embedding VECTOR(1536)
);

这段定义表达了字段和维度，不能替代索引定义。若应用还依赖外部检索服务，写入顺序、失败补偿和删除同步仍然由应用负责。尤其不要把官方 issue 中的架构草案写成已经发布的 SQL 语法。

两种 InnoDB 设计路线差在哪

官方架构讨论把问题拆成两个方向：把向量索引作为普通二级索引体系中的一种 InnoDB 管理对象，或者把它放进由 InnoDB 管理的隐藏子表。前者更接近现有索引管理习惯；后者可以把算法需要的元数据、分区或图结构隔离出来。两者都要回答同一组问题：一行向量更新时，哪些页会改变，回滚和崩溃恢复如何接上，查询候选行如何回到主表做可见性判断。

这也是为什么“直接外挂一个向量引擎”与“原生接入 InnoDB”不是同一层面的选择。原生方案的收益是事务、MVCC、备份和恢复可以沿用数据库机制，代价是索引页布局、内存核算、更新局部性以及查询算子都要进入数据库内核。官方议题还没有给出最终决策，生产环境不应提前绑定某个未定接口。

应用现在怎么落地与验收

如果今天就要做检索，建议把 item_id 作为唯一锚点：业务表保存正文、版本号和 VECTOR 列，外部检索服务保存可搜索副本。写入成功后记录同步状态；更新和删除都带上版本号，定时按版本差异做一致性校验。这样未来 MySQL 原生索引真正可用时，只需替换检索依赖，不必重做业务主键和数据模型。

验收至少看三项：业务表中的向量维度是否统一；外部索引中的文档主键是否都能回到业务表；删除或重算 embedding 后，校验任务能否发现版本落后。把迁移开关放在应用配置层，先让少量请求走新链路，观察召回结果和同步积压，再决定是否扩大范围。

常见问题：别把提案当成可执行特性

MySQL 有了 VECTOR 列，就能直接 ORDER BY 距离吗？

不能这样推断。列类型只说明存储表达，距离函数、索引和查询优化能力要以目标版本的官方手册为准。

原生向量索引为什么一定要讨论 InnoDB？

因为索引更新需要和行数据的提交、回滚、MVCC 可见性及崩溃恢复保持关系，不能只看算法本身。

现在已经使用外部向量服务，是否要立刻迁移？

不建议仅凭架构议题迁移。先把主键、版本和补偿校验做好，等正式版本给出稳定语法、索引限制和运维文档后再做小流量切换。

判断这项能力是否成熟，关键不是看到一个 VECTOR 字段，而是确认目标版本是否同时提供可验证的索引语法、距离查询、更新语义和恢复说明。