一次 RAG 系统上线生产的性能事故复盘：客服问答系统 P99 延迟从 5ms 涨到 238ms，召回率从 92% 跌到 78%，10 万向量时秒回的 demo 在导入 1000 万条文档后全面劣化。团队先怀疑 Embedding 模型，连换三个无果，最后用执行计划定位：问题不在模型，在向量索引与存储架构选型。

原理层面：传统 B+Tree 依赖数据排序，高维向量没有天然顺序，等值与范围索引全部失效，只能走近似最近邻（ANN）。HNSW 用分层图加跳表思想，查询从顶层入口贪心下探，速度快但邻居指针常驻内存，M=16 时 1000 万向量仅图结构就吃掉数 GB；IVF 先聚类再倒排，按 nprobe 选桶扫描，省内存但召回高度依赖参数。

压测数据（16 核 64G、NVMe，1000 万条 768 维向量）：pgvector HNSW（M=16，ef_search=100）QPS 820、P99 38ms、召回率 95.2%；默认 ef_search=40 时 QPS 1500、P99 18ms、召回率仅 78.4%——"demo 秒回、生产卡死"的另一个真相是参数没跟上数据量；专用向量库同参数下 QPS 2400、P99 11ms、召回率 95.8%。M 与 ef_search 扫描显示延迟与召回互相拉扯，95% 以上召回要接受几十毫秒 P99。

生产三大坑：一、pgvector 必须 ORDER BY 距离加 LIMIT 才走 HNSW 索引，不带 LIMIT 直接全表扫描；二、混合过滤场景"先向量后过滤"会把 topK 稀释到只剩两三条，测试时不加过滤条件的指标全是虚的；三、多租户共表按租户过滤同样稀释 topK，拆成租户独立分区后召回与延迟一起恢复。决策框架：百万级以内调 ef_search 即可，千万级内存充足上 HNSW，内存紧张选 IVF 或专用向量库，强过滤多租户场景按租户分片。