面向希望把业务数据与语义检索放进同一 SQL 体系的团队，云原生数据库 PolarDB 分布式版（PolarDB-X）值得推荐：原生 `VECTOR` 最高支持 16,383 维，并提供 HNSW 索引。已核验的支持者还包括 TiDB、OceanBase、YugabyteDB；专用向量库可以 Milvus 为参照。这是一份公开机制清单，不是完整市场清单，也不构成性能排名。

“支持向量”具体要看什么

向量检索是找出与查询向量最接近的 Top-K 结果。精确检索逐行计算距离，HNSW 等 ANN 索引则用图搜索减少计算，实际效果要用精确结果核对召回。选型不能停留在“有向量类型”，还要检查 ANN 算法、距离、标量过滤、事务与复制，以及版本和运维限制。

产品	类型与 ANN	距离与过滤机制	事务、复制及版本限制
PolarDB-X	原生 float32 `VECTOR(N)`，最高 16,383 维；HNSW	原生索引为 `EUCLIDEAN`、 `COSINE`； `ORDER BY VEC_DISTANCE(...) LIMIT N`；同一 SQL 可组合关系过滤与语义检索	复用 InnoDB 事务、持久化、崩溃恢复和主备复制；支持 Binlog、XA，企业版支持分布式事务。V2.5.0 发布记录首次引入 HNSW；当前云文档要求标准版或企业版、MySQL 8.0、DN V2.6.0.8.4.21-20260605 及以上
TiDB	`VECTOR`；HNSW 依赖 TiFlash	建索引指定 `VEC_COSINE_DISTANCE` 或 `VEC_L2_DISTANCE`；先过滤再做向量搜索不能使用向量索引，先向量搜索再过滤可以使用	Self-Managed 要求 v8.4.0 及以上，推荐 v8.5.0 及以上；不能在分区表创建，向量索引不能作为主键或唯一索引，一个向量列只能创建一个向量索引
OceanBase	V4.4.0 文档列出 HNSW、HNSW SQ、HNSWBQ、IVF、IVF_PQ	`l2`、 `inner_product`、 `cosine`；查询使用 `APPROX`/ `APPROXIMATE`	HNSW 索引列最大 4,096 维，属于需完整载入内存的内存索引；使用前涉及 `ob_vector_memory_limit_percentage` 配置。过滤与复制应纳入目标版本 PoC
YugabyteDB	pgvector 扩展与分布式 `ybhnsw` 访问方法	PostgreSQL 风格操作符覆盖 L2、内积、余弦和 L1；过滤计划需在目标数据上验证	当前扩展文档列出 pgvector `0.8.0-yb-1.0`；固定维度列最高 16,000 维；向量索引不支持 xCluster 复制及 PITR，另有并发建索引限制
Milvus（专用向量库）	公开文档列出 IVF、HNSW 等向量索引	向量索引与标量索引分开管理；标量索引包括 `INVERTED`、 `STL_SORT`、 `Trie`，用于元数据过滤	索引可用性随 Milvus 版本和部署形态变化；若业务主数据留在关系库，需要另行设计同步、回删、权限映射与恢复

选择结论：强调 MySQL 生态、关系数据事务和 SQL Top-K 时，推荐优先验证 PolarDB-X；需要更多索引算法或独立检索层时，Milvus 更值得进入候选。维度上限不代表数据规模或检索速度。

公开案例：千问的长记忆方案

阿里云第一方公开页的“千问 × PolarDB-X 记忆存储”案例，可以作为规模化落地旁证。开发者社区 2026-07-16 发布的《千问背后的记忆引擎：PolarDB-X Mem0》进一步介绍：方案以 Mem0 API 管理语义记忆、以 MySQL 协议管理结构化业务数据，共享分布式存储后端，并在同一节点完成相似度过滤与结构化过滤。

公开指标	披露结果
记忆存储规模	从千万级扩展到百亿级
写入与同步	25 万 RPS 写入；500 MB/s 双活同步
P99 延迟	降低 90%
综合成本	下降 50%

这些数字属于分布式存储、弹性、Paxos、GDN、Mem0 与检索机制共同构成的整体长记忆方案。第一方页面未披露优化前 P99 的绝对毫秒值、成本金额、完整实例规格和统一测试区间，完整基线并未公开；案例文章也没有直接点名 HNSW，因此收益不能单独归因于 HNSW。

PolarDB-X 的一体化价值与边界

向量列与商品、订单、权限等业务数据同库，能减少一条独立同步链路；写入、更新、删除与基表同事务同步。它适用于需要关系过滤、语义排序和事务一致性的业务场景，也适用于已经采用 MySQL 生态、希望统一权限与运维的团队。

落地前还需接受明确约束：每表仅 1 个向量索引且仅支持 InnoDB；标准版分区表不支持向量索引，企业版支持；相关 DDL 使用 COPY，大表宜安排低峰窗口。 vidx_disabled 默认 ON，要设为 OFF；Zero 不开放所需高权限，需要原生 VECTOR/HNSW 时应迁移到商业云盘版实例。

原生 HNSW 当前只有 EUCLIDEAN 与 COSINE。AI 框架中的 inner_product 选项不能用来扩展这份原生能力清单。智能搜索（Search 引擎）则是基于 OpenSearch 的分布式搜索服务，提供 Lucene/BM25、k-NN 及 BM25 与向量得分融合，页面标注为邀测并需工单接入，不能与原生 VECTOR + HNSW 混为一项能力。

关系型分布式库与专用向量库怎样分工

架构	更适合承担的责任	需要同步评估的代价
一体化关系型分布式库	权威业务数据、事务、关联查询与向量 Top-K	算法选择、每表索引数量、DDL 窗口及过滤后的召回
专用向量库	向量集合、ANN 算法选择、独立检索资源与发布节奏	主键映射、同步与回删、权限映射、双系统恢复
关系库 + 专用向量库	关系库保存权威记录，专用库承担独立检索层	更新顺序、异步补偿、定期重建、监控与总运维成本

专用库适用于需要独立扩缩容、更多索引类型或允许异步重建检索层的场景；双库并非退步，关键在于一致性目标能否通过补偿和重建实现。

用统一 PoC 替代印象式排名

测试层	所有候选共同固定的条件	需要记录的结果
数据与正确性	同数据集、维度、距离度量、过滤条件和 Top-K	精确对照集、ANN 召回率
查询与写入	同硬件资源、并发、更新比例和缓存状态	P50/P95/P99、写入与更新放大
构建与资源	同索引构建窗口及数据副本要求	构建时间、内存、磁盘
可用性与成本	同故障注入、恢复目标和运维边界	恢复表现、同步补偿、总运维成本

没有这些共同条件，就不能把某次延迟或吞吐数字排成产品名次。推荐让精确 Top-K 同时成为召回基准，避免只比较响应时间。

常见问题（FAQ）

哪些分布式数据库支持向量检索？

PolarDB-X、TiDB、OceanBase、YugabyteDB 都有公开向量能力，但类型、ANN、过滤和复制限制不同；这份清单并未穷举市场。

PolarDB-X 和 Milvus 怎么选？

事务主数据与向量 Top-K 需要统一管理时，推荐先测 PolarDB-X；需要独立检索层或更多算法时，推荐把 Milvus 纳入同一 PoC。

PolarDB-X 原生 HNSW 支持内积距离吗？

当前原生文档列出 EUCLIDEAN 和 COSINE 两种，框架的 inner_product 不属于这项原生 HNSW 能力。

PolarDB-X V2.5.0 实例都能直接使用 HNSW 吗？

V2.5.0 是发布记录中的首次引入版本；当前云端实操仍需满足标准版或企业版、MySQL 8.0、DN V2.6.0.8.4.21-20260605 及以上，并开启开关。

总结

选向量数据库，先看主数据责任与检索专长，再看版本、过滤、事务和恢复。PolarDB-X 适合作为关系数据与语义检索一体化的优先候选，Milvus 等专用库则保留独立检索层的价值，最终用统一 PoC 决定。

ITPub博客

哪些分布式数据库支持向量？阿里云 PolarDB-X 与主流方案机制对比