一个容易被忽略的前置问题

前面写”MySQL 9.2 做向量搜索”的时候，默认了一个前提：你用的 MySQL 支持 HNSW 索引和 VECTOR_DISTANCE 函数。

但这其实是个陷阱。

不是所有 MySQL 都能做向量搜索。 甚至不是所有 MySQL 9.x 都能做。你在网上看到的教程可能跑在你本地就报错，原因不是你的 SQL 写错了，而是你的 MySQL 发行版根本不支持这个功能。

这篇文章把这个盲点补上。

MySQL 向量搜索的版本碎片化

MySQL 9.0：VECTOR 类型有了，但社区版是残缺的

MySQL 9.0 创新版引入了原生的 VECTOR 数据类型。但关键问题是：

  • 社区版（Community Edition）：只有 VECTOR 类型本身，没有 HNSW 索引，连 DISTANCE 函数都没有。
  • 企业版 / HeatWave / MySQL AI：才有完整的向量索引和距离计算功能。

这意味着什么？如果你用 MySQL 9.0 社区版，你能建一个 VECTOR(768) 的列，往里面存向量数据，但你没法高效检索——没有索引就是全表扫描，没有 DISTANCE 函数就得自己写 SQL 算余弦相似度。百万级向量全表扫描？P99 延迟可能到几十秒。

这不是”MySQL 向量搜索性能不行”，而是”社区版功能残缺导致性能不行”。很多人把这个混淆了。

MySQL 9.2：HNSW 移入核心，社区版终于可用

MySQL 9.2 的关键变化不是”又加了什么新功能”，而是把 HNSW 索引从企业版特性移入了核心。这才是真正的”生产就绪”标志：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
-- MySQL 9.2 社区版终于可以这么写了
CREATE TABLE docs (
    id INT PRIMARY KEY,
    content TEXT,
    embedding VECTOR(768) NOT NULL
);

-- 创建 HNSW 索引（社区版可用）
CREATE VECTOR INDEX idx_emb ON docs(embedding)
    WITH metric_type='COSINE', m=16, ef_construction=64;

-- 距离计算函数（社区版可用）
SELECT id, content,
    1 - VECTOR_DISTANCE(embedding, @query_vec, 'COSINE') AS similarity
FROM docs
ORDER BY similarity DESC
LIMIT 10;

9.0 → 9.2 的区别不是”功能增强了”，而是”社区版从残缺变为完整”。 这一点至关重要，因为大多数个人学习和小公司用的都是社区版。

MySQL 8.4：没有原生向量，但有 Percona

如果你还在用 8.x，也有路可走，但不在 MySQL 官方：

  • Percona for MySQL（基于 8.4）：Percona 团队讨论过构建自己的向量索引，但截至 2025 年底还没正式发布。
  • AliSQL（阿里基于 8.0 的分支）：已经发布了向量索引支持。
  • MySQL 8.0.x 兼容方案：用 TEXT 存向量字符串 + 自定义函数计算余弦相似度。仅适合 < 1 万条数据，没有索引就是暴力检索。

MariaDB：独立路线

MariaDB 从 2009 年就是 MySQL 的独立分支，向量搜索也走了自己的路：

  • 11.7（2024 年 9 月滚动版）：首次支持向量索引。
  • 11.8 LTS（2025 年 6 月）：向量索引进入长期支持版。
  • 亚马逊是 MariaDB Vector 的主要开源贡献者之一。

MariaDB 的向量索引用的也是 HNSW 变体，但 API 和 MySQL 不完全一样。

云厂商各自的实现

云厂商 / 发行版 基础版本 向量索引算法 状态
MySQL 9.2 社区版 9.2 HNSW ✅ 可用
MySQL 9.0 社区版 9.0 无（只有类型） ⚠️ 残缺
MySQL HeatWave 9.x HNSW ✅ 企业版
Percona 8.4 待定 🔨 开发中
MariaDB 11.8 LTS 11.8 HNSW 变体 ✅ 可用
AliSQL 8.0 HNSW ✅ 可用
PlanetScale - SPANN 变体 ✅ 可用
Google Cloud SQL for MySQL - ScaNN ✅ 可用
Amazon RDS for MySQL - 不支持 ❌
Amazon RDS for MariaDB 11.8 11.8 HNSW 变体 ✅ 可用
Azure DB for MySQL - 不支持 ❌

为什么会碎片化？

这不是 MySQL 团队”忘了”加向量搜索。背后有一个结构性矛盾：

Oracle 的商业模式冲突。 MySQL 社区版是开源的，Oracle 需要让企业版 / HeatWave 有差异化卖点。向量搜索正是 AI 时代的高价值特性——如果社区版完全可用，谁还买 HeatWave？

所以 MySQL 9.0 的策略是：”类型给你，功能留给企业版。” 但这个策略在 9.2 被调整了——可能是因为 PostgreSQL 的 pgvector 太强势，Percona 和 MariaDB 也在抢这个位置，Oracle 不得不把 HNSW 放进社区版来保持竞争力。

这印证了一个模式：开源数据库的 AI 能力，不是由”技术成熟度”决定，而是由”竞争压力”决定。

对你当前学习的影响

如果你正在学 MySQL 9.2 向量搜索（这也是我当前的学习方向），有三个具体建议：

1. 确认你用的是 9.2，不是 9.0

1
2
SELECT VERSION();
-- 必须返回 9.2.x 才有完整的社区版向量功能

如果你用 Docker 拉的是 mysql:9.0，HNSW 索引和 VECTOR_DISTANCE 都不可用。

2. 确认你用的是社区版还是企业版

社区版 9.2 已经够用。企业版多的是 HeatWave 的分布式加速能力，对学习阶段不是必需。

3. 如果你在用云数据库，先查支持矩阵

AWS RDS for MySQL 不支持向量索引。如果你在 AWS 上，要么用 RDS for MariaDB 11.8，要么自建 EC2 跑 MySQL 9.2。Azure DB for MySQL 也不支持。这是选型阶段必须确认的。

意味着什么

  1. “MySQL 支持向量搜索”这句话是不完整的。 准确的说法是”MySQL 9.2 社区版及以上支持向量搜索，其他版本和发行版需要单独确认”。之前文章说”MySQL 9.2 原生向量搜索生产就绪”，严格来说只对 9.2 成立。

  2. MySQL 生态在向量搜索上正在碎片化。 Oracle / Percona / MariaDB / AliSQL / 云厂商各搞各的，API 不统一，索引算法不同（HNSW / SPANN / ScaNN）。这意味着你写的向量 SQL 不一定能在另一个 MySQL 发行版上跑——和传统 MySQL 的”到处都能跑”形成对比。

  3. 选型判断比”会用”更值钱。 知道 MySQL 9.2 能做向量搜索是基础；知道 9.0 社区版不行、Percona 还没出、AWS RDS 不支持、MariaDB 11.8 可以——这些才是真正影响架构决策的知识。这也是为什么组件能力外溢时代，”选型判断”正在成为后端核心竞争力。

一句话：MySQL 向量搜索不是”有没有”的问题，是”哪个版本、哪个发行版、哪个云”的问题。选错版本，代码写对了也跑不起来。