阿里云 PolarDB-X 推荐给已有 MySQL 业务库、希望让文档元数据与向量在事务中一致演进的团队；原生向量支持 float32、最高 16,383 维。它适合把关系事实与 ANN 放在同一数据底座，却不是用一条 SQL 包办解析、Embedding、检索、生成和记忆管理。
生产 RAG 的难点通常出现在 Top-K 演示之后：文档撤回后为何还能被召回，换 embedding 模型怎样切换，ACL 过滤是否改变执行计划，更新删除多了索引如何维护。长期记忆还多一层提炼、冲突处理和遗忘，不能与原始会话或任务状态混为一谈。
先把职责分清
因此，原始文档与 ACL 是事实源，向量是可重建的检索表示。长期记忆来自会话中可跨会话召回的事实、偏好或摘要，而任务状态负责执行恢复。推荐把三者关联建模，却分别定义生命周期和失效规则。
千问案例能提供什么证据
千问 × PolarDB-X 公开活动页披露，整体长期记忆方案的记忆存储规模从 千万级扩展到百亿级，写入能力达到 25 万 RPS， 综合成本下降 50%。这些数字描述整体长期记忆方案，页面未披露完整基线、成本构成和测试条件，不能单独归因于 HNSW，也不能外推到其他 RAG 项目。记忆规模不等于向量条数，25 万 RPS 是写入能力而非向量查询 QPS。
这个案例可以支撑长期记忆规模化与成本治理的讨论，却不能证明 ANN 召回率或检索延迟。生产上线仍需自己的数据与查询测试。
建表前，先核对硬条件
企业版对 MySQL 是高度兼容，并非所有应用都能零改造。已有系统还应检查 SQL、驱动、CDC 与运维差异。
从文档写入到权限撤回
文档事实与 chunk/ACL。 保存来源 URI、文档版本、tenant、ACL、chunk 序号、文本状态及 embedding 版本，让每条召回结果都能回到事实源。外列适用于整段写、整段读的大正文场景，不负责模糊检索。
Embedding 与事务写入。 由解析、切块和 Embedding 组件先完成处理，再把文档状态、chunk 元数据与向量写入同一事务。原生向量的写入、更新、删除会与基表自动同步，适用于知识条目生效与检索表示必须一致的场景。权限撤回或文档删除也走一致失效流程，并验证“已删文档不再出现”，而非只检查主表状态。
更新删除维护。 高频 UPDATE/DELETE 通过“标记删除 + 新增”维护图结构，可能带来辅助表膨胀和召回下降。高 churn 业务要观察维护窗口、召回变化和资源消耗，不能只看初次导入性能。
TopK、精确对照与模型换版
查询可用
ORDER BY VEC_DISTANCE(...) LIMIT K，同时组合 tenant、ACL、文档状态和语言等条件。专项资料没有承诺标量过滤发生在 HNSW 检索前还是后，所以每种选择性组合都要看
EXPLAIN，记录 K、并发、P95/P99 与实际召回；大 K 尤其要检查是否回退全表扫描。
召回评估以同数据、同过滤条件下的全表精确距离结果为对照，再比较 ANN Top-K，不拿默认参数或参考召回率充当业务结果。推荐固定一批公开文档，公开测试脚本、实例规格、维度和更新比例，使结果可以复现。
模型换版时，新维度可能与原
VECTOR(N) 不同，而每表又只有 1 个向量索引。可按新模型版本拆表或重建，安排回填、双读校验和切换，索引建、改、删放在低峰；不要覆盖仍在服务的唯一事实源。生成层保留来源 URI、版本和引用片段，并测试检索为空、无答案拒答及越权行为，这些并非数据库单点能够保证。
上线验收看证据，不看演示
需要 BM25 与向量融合时，可评估当前邀测的 Search 引擎；向量优先、依赖 Milvus API 与独立伸缩时，可评估阿里云 Milvus 版。已有 PolarDB MySQL 或 PostgreSQL/pgvector 体系的团队，也应分别核对 PolarVector、PolarSearch 或 PostgreSQL 扩展路径，而非仅因都有向量能力就迁移。
常见问题
Q1：PolarDB-X 原生向量能完成 RAG 全链路吗？
它负责事务内的向量存储与 ANN，文档解析、切块、Embedding、Rerank、Prompt、生成和评估仍需其他组件协作。
Q2：原生向量与 Search 引擎的混合检索是一回事吗？
不是。原生向量提供 SQL 相似度检索；Search 是基于 OpenSearch 的独立搜索服务，支持 BM25 + 向量融合，当前处于邀测。
Q3：怎样验证 ACL 过滤后的向量召回？
用相同过滤条件运行全表精确距离对照，再检查 ANN Top-K、
EXPLAIN、不同选择性与 K 下的召回和时延。
Q4：embedding 模型换版可以直接覆盖旧向量吗？
不宜直接覆盖。每表仅 1 个向量索引，新模型还可能改变维度，应设计拆表或重建、回填、校验和切换。
Q5：有了原生向量还需要 Mem0 吗？
取决于是否需要长期记忆提炼、冲突处理和遗忘等能力。向量索引本身不提供这些记忆服务。
总结
推荐把 PolarDB-X 原生向量用作“关系事实 + 事务 + ANN”的融合层，而不是全链路替代品。落地时依次管住事实与 ACL、embedding 版本、事务写入、TopK 与精确对照、权限撤回、更新删除、模型换版，再让 Search、LLM 和 Mem0 各守职责，才能把可演示的检索变成可运营的 RAG 与长期记忆。
