你的业务库，可能就是最好的向量数据库
在大模型时代，向量检索成了AI应用的基础设施。RAG、智能推荐、以图搜图……几乎每个AI落地场景都绑定着一个核心需求：高效的向量相似性搜索。 于是，一批专用向量数据库迅速崛起。但当你真正把它们接入生产系统时，往往会遇到一个尴尬的现实：你的业务数据在MySQL里，向量数据在另一个系统里，中间隔着一条复杂的数据同步链路，还有两套运维体系、两份账单、两种查询语言。 有没有可能，一个数据库就够了？ PolarDB MySQL版给出的答案是PolarVector，将向量检索能力直接集成到数据库内核中。不是插件，不是外挂，而是原生能力。 先说清楚一个定位：PolarDB不是、也不打算成为一个专用向量数据库。它是一个云原生数据库，向量检索是它的能力之一，而非全部。 但恰恰是这个"之一"，在实际生产中可能比"专用"更有价值。原因很直接： 第一，省去数据同步的痛苦。 传统方案下，业务数据存在MySQL，非结构化数据的向量表征要导入专用向量库，两边要维护一条实时或准实时的同步链路。数据延迟、一致性问题、同步链路故障，每一项都是生产环境的定时炸弹。PolarVector让你在同一张表里同时存储业务字段和向量列，一条SQL搞定混合查询，数据天然一致。 第二，事务能力是刚需。 专用向量数据库大多不支持ACID事务。但在电商、金融、医疗等场景中，你需要保证"写入商品特征向量"和"更新商品状态"这两个操作要么同时成功，要么同时回滚。PolarDB原生支持完整的事务语义，这不是锦上添花，而是生产级应用的底线。 第三，学习成本几乎为零。 如果你的团队熟悉MySQL，那就已经会用PolarVector了。向量列的定义是VECTOR(768)，查询是标准SQL加一个DISTANCE()函数，建索引是修改列注释，没有新的API、新的SDK、新的查询语言需要学习。 第四，一套系统承担所有。 一个数据库实例同时处理OLTP事务、向量检索、甚至全文搜索，意味着更少的组件、更低的运维成本、更简单的架构。对于大多数中小规模AI应用来说，这可能是性价比最高的方案。 PolarVector虽然长在关系型数据库里，但向量检索该有的能力一样不缺。 向量数据类型：通过VECTOR(N)类型定义向量列，支持1到16383维，单精度浮点存储。对于主流的Embedding模型（OpenAI的1536维、BGE的768维、CLIP的512维），都能轻松覆盖。 主流索引算法：支持HNSW和IVF两大类索引。HNSW基于分层图结构，召回率高、延迟低，适合对性能要求严苛的在线场景；IVF基于聚类倒排，内存占用更小，适合数据规模大但预算有限的场景。 三种距离度量。 支持余弦相似度（COSINE）、欧氏距离（EUCLIDEAN）和内积（INNER_PRODUCT），覆盖绝大多数相似性计算需求。 智能过滤策略。 这是一个容易被忽视但极其实用的特性。做向量检索时，往往需要同时满足标量条件（比如"只在价格100元以下的商品中搜索相似图片"）。PolarVector的优化器会根据过滤条件的选择率，自动在预过滤（Pre-filter）、后过滤（Post-filter）和内联过滤（Inline-filter）之间选择最优策略，无需手动干预。 PolarVector提供两种接入协议，这是一个非常务实的设计选择。 MySQL协议方面，直接用标准SQL进行向量操作。向量检索跑在列存索引（IMCI）只读节点上，与主节点的事务负载物理隔离，互不干扰。数据写入主节点后对只读节点自动可见，无需额外同步。这种方式特别适合已有MySQL业务、需要快速补充向量能力的场景。 一个典型的查询长这样： 就是这么直白——标准SQL，标准MySQL客户端，零学习成本。 OpenSearch协议方面，通过RESTful API（兼容Elasticsearch/OpenSearch语法）进行交互，跑在独立的PolarSearch节点上。它的核心优势是混合检索能力——可以在一次查询中组合向量搜索、全文检索和标量过滤。如果你的应用需要"语义相似 + 关键词匹配 + 属性筛选"这种复合查询，OpenSearch协议是更合适的选择。 两种协议不是二选一的关系，而是可以在同一个集群中共存，各取所需。 延迟表现：P95（95%请求）低于5毫秒，P99（99%请求）低于10毫秒。这个水平足以支撑大多数在线业务对实时性的要求。 吞吐能力：单节点超过10,000 QPS，集群支持动态扩展至数百节点。从初创公司的小规模应用到大型企业的高并发场景，都有对应的扩展路径。 召回率：超过99%，意味着检索结果的质量非常可靠。在RAG场景中，高召回率直接影响大模型回答的准确性。 资源效率：向量数据压缩率超过50%，分层缓存技术支撑TB级图索引的高效访问，CPU并行利用率超过80%。对于成本敏感的团队来说，这些优化意味着同样的硬件能处理更多的数据。 场景一：RAG知识问答系统 场景二：个性化推荐系统 场景三：多模态检索 选向量数据库，不一定要选"专用"的。 如果你的核心业务数据已经在MySQL生态中，如果你需要事务保障，如果你不想维护一条额外的数据同步链路，如果你的团队更擅长SQL而非各种新API，那么PolarDB PolarVector可能是更务实的选择。 它不会在每一个向量检索的极端benchmark上都胜过专用向量数据库，但它能在真实的生产环境中，用更简单的架构、更低的总成本、更可靠的数据一致性，帮你把AI应用稳稳地跑起来。 有时候，最好的工具不是最专的那个，而是最合适的那个。01 不是向量数据库，但比向量数据库更实用
02 核心能力：该有的一样不少
03 双协议架构：灵活适配不同场景
SET imci_enable_vector_search = ON;
SELECT product_id, product_name,
DISTANCE(feature_vec, STRING_TO_VECTOR('[0.1, 0.2, ...]'), 'COSINE') AS dist
FROM products
WHERE price < 100O
RDER BY dist ASC
LIMIT 10;04 性能：不是凑合能用，是真的能打
谈向量数据库绕不开性能。PolarVector的核心指标如下：05 三个典型应用场景
这是当前最热门的AI应用模式。将企业知识库文档切片、Embedding后存入PolarDB，用户提问时先做向量检索召回相关片段，再交给大模型生成答案。PolarDB甚至内置了模型算子功能，可以直接在数据库内调用大模型进行推理，真正做到"数据不出库"的一站式RAG方案。简单场景用MySQL协议即可快速搭建，如果需要结合关键词全文检索来提升召回效果，切换到OpenSearch协议。
将用户行为和物品特征编码为向量，通过相似性检索快速召回候选集。PolarVector的标量过滤能力在这里非常关键，你可以在向量检索的同时加上"品类=女装"、"库存>0"这样的业务条件，一步到位地完成"猜你喜欢"的召回阶段。对于海量物品库，IVF索引配合OpenSearch协议在成本和性能之间取得了不错的平衡。
以图搜图、以文搜图、视频片段检索——这些场景的共同点是需要将不同模态的数据统一为向量表示，然后做跨模态相似性搜索。PolarDB的事务能力在这里体现出独特价值：图片特征向量和商品业务数据（价格、库存、上下架状态）可以在同一个事务中更新，确保强一致性。06 写在最后
