AliSQL 向量技术解析（一）：存储格式与算法实现

随着 AI 与大模型应用的普及，高维向量作为表征复杂数据（如文本、图像、语音）的关键载体，其存储与高效检索需求在推荐系统、图像检索、自然语言处理等领域快速扩展，对数据库技术提出了新的挑战。向量应用场景催生了专用的向量数据库，也推动了传统数据库对向量能力的支持。

在此背景下，PostgreSQL 通过 pgvector 插件实现了向量的高效检索能力，而 MySQL 生态则长期缺乏原生支持。虽然在 MySQL 9.0 发布了 VECTOR 数据类型，但其向量距离计算函数仅支持在 HeatWave 中使用，且未提供通用的向量索引能力。这一技术空白使得企业需依赖独立部署的向量数据库或迁移数据以实现高维计算需求。

AliSQL 基于 MySQL 8.0 原生扩展了企业级向量数据处理能力，提供开箱即用的向量化解决方案，通过标准 SQL 接口无缝集成高精度向量匹配与复杂业务逻辑，助力企业以低成本、高兼容性架构快速落地 AI 创新应用。

本文基于 AliSQL 8.0 20251031 版本，聚焦向量索引的核心实现，从存储格式到算法实现，帮助读者更好地了解和使用向量能力。

AliSQL 原生支持最高 16,383 维向量数据的存储及计算，集成主流向量运算函数包括余弦相似度（COSINE）、欧式距离（EUCLIDEAN），并支持对全维度向量列建立基于 HNSW（Hierarchical Navigable Small World）算法构建的向量索引。

创建带有向量索引的表，插入数据并进行向量搜索。

# 创建带有向量索引的表CREATE TABLE `t1` (  `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,  `animal` VARCHAR(10),   `vec` VECTOR(2) NOT NULL, # 新增vector类型列  VECTOR INDEX `vi`(`vec`) m=6 distance=cosine # 显示指定m和distance  );
# 插入数据INSERT INTO `t1`(`animal`, `vec`) VALUES  ("Frog", VEC_FROMTEXT("[0.1, 0.2]")),  ("Dog", VEC_FROMTEXT("[0.6, 0.7]")),  ("Cat", VEC_FROMTEXT("[0.6, 0.6]"));
# 向量搜索SELECT `animal`, VEC_DISTANCE(`vec`, VEC_FROMTEXT("[0.1, 0.1]")) AS `distance` FROM t1 ORDER BY `distance`;

结果示例

|--------|---------------------------|| animal | distance                  ||--------|---------------------------|| Cat    | 0.00000001552204198507212 || Dog    |     0.0029455257170004634 || Frog   |       0.05131670194948623 ||--------|---------------------------|

也可以在已经存有向量的表上建立向量索引。

# 向量列转换ALTER TABLE `t1` MOdify COLUMN `vec` VECTOR(2) NOT NULL;# 创建向量索引CREATE VECTOR INDEX vi ON t1(v); # 不显示指定m和distance，则默认使用参数值

HNSW 作为最为流行的 ANN 算法之一，在机构测评和工程实现上取得了广泛的认可和验证。目前 AliSQL 优先支持了基于 HNSW 算法的向量索引，向量搜索总体架构如下图所示。

• ANN 查询经过代价估计后选择合适的索引进行搜索，也可以用 FORCE INDEX 等 hint 指定向量索引进行搜索。

• 逻辑上有一张完整的 HNSW 图，该图的信息被组织成一张辅助表持久化存储在磁盘中，表中每行数据代表 HNSW 图中的一个节点，在这张图上流转 HNSW 算法即可实现向量的插入和检索。

• 不同于普通索引直接访问存储引擎，引入了向量索引插件，在内存中维护一个 HNSW 图的 Nodes Cache，提高查询效率。

HNSW（Hierarchical Navigable Small World）是一种基于多层图结构的高效近似最近邻（ANN）搜索算法，由论文《Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs》提出。其设计可以概括为：

• 【分层跳表】第 0 层的图有全部点的信息，从低往高，高一层的图是低一层图的缩略图，只有低一层图的部分点，顶层用于快速跳转，底层用于精确搜索。

• 【连接近邻】每一层都是根据向量距离连接的邻近图，每个点都记录它最近的几个点作为邻居。

最近邻搜索 Search Layer

插入算法 Insert

搜索算法 KNN Search

实现 HNSW 算法，需要在数据库中将 HNSW 图结构存储下来。设计辅助表结构如下表所示，每行数据对应于图中的一个节点的所有信息，所谓一个节点是包括了第 0 层到其存在的最大层数的所有映射点。

1. gref 表示 graph ref 即辅助表主键，用于邻居节点的搜索，使用 InnoDB 的系统列 ROW_ID。

2. layer 上建立一个 KEY，用于快速定位整张图的入口节点即 layer 最大的节点。

3. tref 表示 table ref 即原表主键，用于向量搜索完成后进行回表，使用 server 层的存储格式。假设主表主键是一个值为 1 的 int 列，在 InnoDB 引擎层存储为 80 00 00 01，辅助表则使用 server 层的存储格式，将其存储成 01 00 00 00 的小端序 BINARY 列。

4. vec 辅助表上的向量使用半精度 int16 格式存储，精度转换后，还需要记录转换的缩放因子 scale，存储为 float32 位于首 4 字节，该转换过程可以牺牲一定精度，有效降低存储空间并提升搜索效率。

5. neighbors 包括节点从第 0 到最高层的每一层的邻居，每一层存储 1 字节邻居数量和每个邻居的 gref，算法流转时就可以在同层邻居之间进行导航搜索了。

[9A 99193F | 3333333F]
原始向量 [0.6, 0.7] 大端序    | 1. 找最大绝对值: 0.7    | 2. 计算scale: 0.7/32767    v缩放因子 scale = 2.13629555e-05    | 3. 量化: 每个元素除以scale并四舍五入    v量化后向量 [28086, 32767]    | 4. 存储: scale(32位float) + dims(16位int数组)    v存储结构: [scale: 2.13629555e-05] [dims: 28086] [dims: 32767] 小端序
[2860 C2 37 | B6 6D | FF 7F]

总的来说，向量索引辅助表通过合理的格式设计和精度转换，对 HNSW 图中的节点信息进行高效存储；建立合理的索引、设计 neighbors 列格式，完整支持了 HNSW 算法；不断从向量索引辅助表加载节点信息，即可运行 HNSW 算法。

不同于普通表，向量索引辅助表对用户不可见，无法直接访问，与主表之间的关系如下图所示。

• 辅助表名使用主表的 table id 拼写为 vidx_<table_id>_00，主表可以利用辅助表名从数据字典（DD）找到辅助表的元数据信息。

• 当要进行向量搜索或更新时，通过主表打开辅助表。

• 通过辅助表 DD 构建辅助表的 TABLE_SHARE 并挂在主表的 hlindex 指针下，辅助表的还会创建一个公共的 Nodes Cache 通过指针 hlindex_data 访问。

• 辅助表的 TABLE 也挂在主表的 hlindex 指针下，并创建 context 对象保存向量搜索的结果集。

• 辅助表的 TABLE_SHARE 不进入 table cache 中，随主表一起关闭。

在 DDL 执行过程中，主表与辅助表的结构变更封装于同一事务，通过 MySQL 的事务系统和 DDL log，可以保障 DDL 操作的原子性与 Crash Safe 特性。

通过设计结构化的向量索引辅助表，AliSQL 完整实现了 HNSW 图的高效存储与算法流转；结合 MySQL 8.0 数据字典（DD）的适配，保障了元数据一致性与 DDL 操作的原子性。这一实现解决了 MySQL 生态在向量处理领域的长期短板，为存量 AliSQL 实例提供了开箱即用的高维搜索能力。

本文聚焦于向量索引的存储与算法实现，但完整数据库能力的可靠性仍需事务性与并发控制的支撑。后续会在《AliSQL 向量技术解析（二）：节点缓存与并发控制》中深入探讨 Nodes Cache 对查询的优化原理，以及向量操作如何通过并发控制和事务隔离满足生产级要求。