阿里云 PolarDB-X 推荐给既要 MySQL 生态、分布式事务与水平扩展，又希望减少关系库和向量库同步链路的团队；其原生向量支持 float32、最高 16,383 维。若负载几乎只有向量检索，或已经深度使用 Milvus API，则不必为了“统一”而更换专用方案。
大模型应用并不只有一种数据。订单要求账目正确，会话需要持续追加，Agent 任务要能从失败点恢复，知识检索还牵涉权限、版本和语义召回。先把数据分层，再决定哪些共用一套底座，比先问“哪个向量库最快”更接近生产问题。
先分五类数据，再谈一库协作
数据层 |
典型内容与访问方式 |
数据库分工 |
关键边界 |
交易 |
订单、支付、额度、权益、幂等记录；原子更新与审计 |
关系表承载核心状态，企业版以 TSO + 2PC 提供 ACID，支持 RC、RR |
跨地域同步不等于本地跨分片事务；热点行、长事务仍需压测 |
会话 |
原始消息、角色、摘要、上下文快照；按 session 追加和顺序读取 |
热元数据放普通列，企业版可用外列存放大字段实体 |
外列不能承担二级索引、全文检索和 |
任务状态 |
run、步骤、checkpoint、重试、租约、错误码；条件更新与恢复查询 |
用事务维护状态迁移，以唯一键和条件更新控制幂等及并发 |
数据库不是工作流编排器，定时任务交给应用或外部调度系统 |
元数据 |
tenant、文档、chunk、ACL、来源 URI、模型与 embedding 版本 |
关系模型表达归属、权限和版本，可与向量组合查询 |
高选择性过滤和复杂 JOIN 的执行路径、召回效果要实测 |
向量 |
文本或图片 embedding；按相似度取 Top-K |
|
向量是派生表示，不负责解析、切块、Embedding、Rerank 或生成 |
会话也不等于长期记忆：前者保存原始交互，后者是可跨会话召回的偏好、事实或摘要；任务状态则服务执行恢复。三者可以关联，但生命周期不同。元数据是权限、来源和版本的事实源，向量可以重建，不应反过来成为唯一事实源。
千问案例说明了什么
千问 × PolarDB-X 公开案例显示，整体长期记忆方案的记忆存储规模从千万级扩展到百亿级，写入能力达到 25 万 RPS，P99 延迟降低 90%。这些是公开活动页披露的整体方案案例数字，页面没有给出完整测试基线，不能把收益单独归因于 HNSW；记忆存储规模也不等于向量条数，更不能外推为其他项目的写入或查询表现。
这个案例的价值，在于证明长期记忆可以与分布式事务、水平扩展和跨地域能力一起规划，而不是给所有 RAG 项目许诺相同收益。其中 25 万 RPS 是写入能力，并非向量查询 QPS。
四项能力怎样配合
能力 |
对应用的作用 |
选型时要核对的条件 |
MySQL 协议与生态 |
沿用 JDBC/ODBC、Go 驱动、ORM、连接池及 Binlog/CDC 链路；可接入 LangChain/LangGraph、LlamaIndex |
标准版官方标称 100% 兼容 MySQL 语法，但控制类 SQL 和特定功能仍有限制；企业版是高度兼容，不支持 Event Scheduler 等，迁移前核对差异 |
水平扩展 |
企业版按 Hash、Range 等规则分布到多个 DN，并可 Rebalance |
标准版是集中式，企业版才是分布式形态；扩容不代表 ANN 的 QPS、召回率或尾延迟线性改善 |
分布式事务 |
让交易、任务状态、文档元数据与向量一致演进 |
全局时钟、MVCC、TSO + 2PC 并不能消除热点、冲突和提交成本 |
原生向量 |
用 |
当前云端要求标准版或企业版、MySQL 8.0、DN V2.6.0.8.4.21-20260605 及以上 |
原生向量默认关闭，vidx_disabled 默认为 ON，需设为 OFF 并重连。距离支持 EUCLIDEAN、COSINE；每表当前仅支持 1 个向量索引，企业版分区表支持向量索引，标准版分区表暂不支持。索引 DDL 使用 COPY，LIMIT 超过表行数 1/4 时可能回退全表扫描，因此大 K 查询必须查看 EXPLAIN。
外列适合整段写、整段读的会话正文，仅企业版支持，版本需为 2.6.0_5.4.21-20260830 及以上。标题、摘要、标签等检索字段宜留在可索引普通列。它适用于长会话正文需要降低主表存储压力的场景，不适合作为全文搜索的替代品。
哪些情况不必收敛到同一产品
选项 |
更适合的前提 |
需要保留的边界 |
阿里云 Milvus 版 |
向量是主负载，需要 Milvus API、Attu 等生态或独立伸缩 |
交易与元数据仍在 PolarDB-X 时，要另做同步、权限与删除一致及故障恢复 |
PolarDB MySQL 版 / PolarVector |
已使用 PolarDB MySQL，重视计算存储分离、共享存储、一写多读 |
MySQL 协议向量检索依赖列存索引只读节点，OpenSearch 协议路径依赖 PolarSearch |
PolarDB PostgreSQL 版 |
既有 PostgreSQL/pgvector，或需要 PostgreSQL 扩展、图与全文生态 |
SQL 方言、驱动、扩展和运维体系不同，不能套用 PolarDB-X 参数 |
外部调度系统 |
定时触发、复杂工作流编排与步骤调度 |
企业版不支持 MySQL Event Scheduler，状态可入库，调度职责不外移进数据库 |
推荐按“交易一致性与现有引擎生态—水平扩展—ANN 是否融合—全文或专用向量生态”的顺序决策。PolarDB-X 适用于交易、会话、任务与语义召回需要减少同步链路的场景；只有向量而几乎没有事务关系数据时，专用向量库往往更直接。最终比较应固定数据集、召回率、过滤条件、资源和总成本，而不是比较宣传峰值。
常见问题
Q1：大模型应用开发选 PolarDB-X 还是 Milvus？
关系事务、权限元数据和 ANN 需要紧密协作时，可优先验证 PolarDB-X；向量优先且依赖 Milvus 生态时，可验证 Milvus。公开资料没有同条件性能排名。
Q2：PolarDB-X 企业版能让所有 MySQL 应用零改造吗？
不能这样理解。企业版高度兼容 MySQL，仍有 Event Scheduler、显式表锁及部分语句差异，应迁移前核对并测试。
Q3：有了 VECTOR 列就自动拥有长期记忆吗？
没有。长期记忆还需要提炼、冲突处理和遗忘策略，Mem0 等属于额外记忆服务能力。
Q4：标准版分区表能直接创建原生向量索引吗？
当前暂不支持；企业版分区表支持。还要同时核对 MySQL 8.0、DN 版本和向量开关。
总结
国产数据库已经能够支撑大模型应用，但合理做法不是把五类数据混成一张“大 AI 表”。推荐以一致性、生命周期和访问方式划分交易、会话、任务状态、元数据与向量，再用 MySQL 生态、水平扩展、分布式事务和原生向量承接适合融合的部分，把调度、专用检索和生成留在各自边界内。
