近年大规模嵌入向量技术被广泛采用,检索与相似度搜索已经成为数据库功能的核心需求。传统基于内存的近似最近邻(ANN)索引在小规模或内存充足的场景中表现出色,但在关系型数据库里面对海量数据、有限内存与强一致性需求时,直接复刻纯内存结构并不可行。如何在 MySQL / InnoDB 这样的关系型存储引擎中,既保证事务性与崩溃恢复,又能高效执行向量搜索,是工程实践中亟需解决的问题。本文从原理到工程实现,深入解析一种被证明可用的混合向量索引设计与维护策略,适合需要在生产环境中部署大于内存向量索引的开发者与数据库工程师阅读和参考。首先理解 HNSW 的优势与局限非常重要。HNSW 是一种层级图结构,利用多层稀疏图快速定位底层节点的近邻,查询时自顶向下收敛到目标区域,单机内存中可以取得很高的召回率和很低的延迟。
然而 HNSW 的设计隐含关键假设:索引能够驻留内存且结构相对稳定。关系型数据库中的索引必须应对连续的插入、删除、更新,同时满足事务隔离与持久性。当数据量远超内存时,单纯将整个 HNSW 放入内存既成本高昂又不现实,频繁重构内存图也会带来可用性与性能问题。因此实用的方案通常采用混合索引架构。在这种架构里,内存保存一个"头索引"(head index),采用 HNSW 或类似图结构,但仅保存全部向量的一个采样子集;其余向量以合并的二进制形式存放在关系型表中,作为按簇或分区组织的 posting lists。头索引承担快速定位簇与引导查询的职责,而磁盘上的 posting lists 存储原始向量数据并由数据库负责持久化与事务保证。
典型的经验值是将头索引规模设为全部向量的 10%~30%,默认 20% 往往在召回与内存使用之间取得较好平衡。通过随机采样构建头索引通常足够鲁棒,当数据规模庞大时采样代表性有统计学支撑;对小规模数据可适当调整以避免不均衡。插入的新向量需要同时被考虑到索引中。混合索引的写入流程一般是:首先在头索引上执行一次 ANN 查询,找到与新向量最近的一个或多个 head;然后将新向量附加到这些 head 对应的 posting lists 中。实现上不能简单地在 B-tree 的单条行值内做原子追加,因为 BLOB 的原地扩展会导致复制与锁竞争,写放大严重。在没有 LSM 引擎的情况下,一个高效做法是为 posting lists 使用复合键结构,例如将表主键设计为 (head_id, seq),其中 seq 为单调增长的序列。
追加操作转换为插入新行而非修改已有行,变为对 B-tree 的友好顺序写入,从而规避行级锁与复制开销。查询时再通过范围扫描收集同一 head_id 下的一系列行并拼接它们得到完整的 posting list。这个方案本质上在 B-tree 上模拟了 LSM 的顺序写优势。持续插入会让某些 posting list 趋于膨胀,从而影响查询延迟。为保证查询性能的上界,必须引入增量重平衡机制。借鉴研究成果与工程实践,可以将重平衡拆解成若干后台小任务,例如拆分(Split)、重分配(Reassign)、合并(Merge)及碎片整理(Defragment)。
拆分在 posting list 超过阈值时触发:将其聚类为多个小块、在头索引中插入新 centroid,并将原 posting list 替换为若干更小的 posting lists。频繁拆分可维持单个列表尺寸,却会引发一个重要问题 - - 局部最优导致的最邻分区分配(NPA)破坏。即单次对某 posting list 做聚类时忽略了临近簇的存在,可能把一些向量分配给非最近 centroid,从而降低召回。为纠正拆分带来的局部分配错误需要重分配操作。重分配旨在把确实更接近其他簇中心的向量迁移到正确的 posting list。工程上需要两个性能保障:高效筛选候选向量,以及低开销的迁移实现。
通过在拆分时利用距离比较的启发式,可以快速排除绝大多数不需要迁移的向量,只对疑似错误分配的少量向量执行后续处理。迁移本身通过追加新版本到目标 posting list 完成,而不立即删除源 posting list 中的旧条目。也就是说,采用版本化策略记录向量的当前生效状态。版本存储占用极小(如一字节的版本计数),并把每个向量的最新版本保存在一个轻量级的内存表中。查询读取 posting list 时会忽略版本过期的条目,这样迁移只需追加写入,极大减少了对原 posting list 的昂贵读写。版本化策略解决了迁移写放大的问题,但会在磁盘上留下大量陈旧数据,降低存储效率并可能影响查询时的 I/O。
为此需要合并操作对老旧或稀疏列表进行重构。合并以某个 head 为中心,收集其附近的 posting lists,去除过期条目并重新生成尺寸合适的 posting list,按需重建或替换 head。合并既能回收磁盘空间,又能重新组织数据以恢复更均衡的簇分布。Defragment 则是纯粹的物理重写,用于在高并发插入期间整理表结构、避免行分裂导致的性能下降。删除与更新问题在带版本的架构中变得轻量。删除只需在版本表中打标或把对应 ID 的版本递增并标记为删除,从而让后续查询忽略该向量,而不必对所有相关 posting lists 做即时改写。
更新可被拆成一次删除和一次插入:在用户表层面更新向量并生成新的向量 ID,然后把旧 ID 标记删除并把新向量按插入流程添加到索引。由于删除与插入都是非阻塞的追加/标记操作,因此能以良好吞吐应对日常需求。事务一致性与崩溃恢复是关系型数据库向量索引实现的关键。把向量数据和 posting lists 存放在 InnoDB 等 ACID 存储引擎之上,可以借助事务保证写入的原子性与持久性。但头索引若保持在内存中就不再天然受数据库事务约束。为此需要把对内存头索引的结构性修改与对 InnoDB 的变更串联起来。
可行模式是为每次后台维护操作使用一个写前日志(WAL),把对头索引的变更先记录到 WAL,并把 WAL 的写入与 InnoDB 事务的提交有关联。只有当 InnoDB 变更提交成功时,才把对应的 WAL 标记为已应用。启动时,通过加载最后一次持久化的头索引快照并回放 WAL,可保证内存头索引与磁盘 posting lists 的一致性。为了避免 WAL 无限增长,周期性对头索引做持久化快照并合并后清理 WAL,是必须的维护任务。由于只有后台维护任务会修改头索引,快照与 WAL 合并可以通过暂停后台任务来实现,而不影响读写路径的延迟与可用性。在工程实现与调优方面,有若干实用建议值得参考。
头索引用量的设置需要结合内存预算与召回要求折中;较大的头索引能提升查询召回且减少后端磁盘扫描,但占用更多 RAM。posting list 的目标大小应能在单次 InnoDB 读取中被高效处理,过大或过小都不理想。版本计数的位宽与 wrap-around 策略要设计谨慎,确保在最坏情况下也能正确处理版本回绕。后台维护任务的调度应与查询负载解耦,可以根据负载自动缩放运行频率,在低峰期做更多合并/重分配以恢复索引质量。监控面向指标应包括单查询延迟、平均扫描向量数、头索引命中率、posting list 的平均与最大长度、以及版本过期率等,这些指标能直接反映索引健康与是否需要触发维护。针对存储引擎的抉择也会显著影响整体复杂度。
使用 LSM 存储引擎(如 RocksDB/MyRocks)能天然支持高效的追加与合并语义,从而简化 posting list 的追加实现,并降低写放大。缺点在于 LSM 在点查和范围扫描上的表现与 InnoDB 不同,需要评估应用的读写型态。现实中折衷做法往往是保留主存储引擎为 InnoDB 以兼容现有 OLTP 负载,同时在索引层通过设计模拟 LSM 特性来获得写入效率,如前述复合键与追加行的做法。未来改进与研究方向包括更智能的 head 采样与动态扩缩容策略、更高效的重分配启发式以减少不必要的迁移、更丰富的成本模型用于触发合并/拆分决策,以及对向量类型与维度的自适应参数调整。对于需要极高吞吐与低延迟的场景,部署专用 LSM 后端或将头索引做分布式持久化以支持更大规模的内存图,也值得考虑。总结关键要点,构建能处理大于内存规模的关系型数据库向量索引需要在数据结构与数据库特性之间做工程上的妥协。
混合索引架构通过把快速的内存 HNSW 与持久的磁盘 posting lists 结合起来,在保证事务语义与崩溃恢复的前提下,实现了可扩展的向量检索。高效的插入依赖写入友好的 posting 列表布局和在 B-tree 上模拟的 LSM 行为;召回与性能维持则依赖连续的后台维护任务包括拆分、重分配、合并与碎片整理;版本化策略为低开销的迁移与删除提供了优雅机制。理解这些设计理念并结合实际业务负载进行参数调优,能够在关系型数据库中实现可靠、高效的向量搜索能力,为具有强一致性要求的生产系统引入 AI 驱动的相似度检索提供可行路径。 。
