RAG 不用向量数据库，用 MySQL 硬扛？暴力搜索的巨坑……

📌 一句话摘要

本文以面试场景切入，系统对比暴力搜索与 ANN 索引的性能差异，详解 HNSW、IVFFLAT 等主流向量索引算法原理，并给出 PostgreSQL + pgvector 在百万级 RAG 场景下的选型理由与实践建议。

📝 详细摘要

文章从一段面试经历引出 RAG 系统中向量检索的核心问题：暴力搜索（全表遍历计算相似度）在 50 万级数据量下延迟达秒级，不可用于生产。随后系统展开向量数据库的必要性、向量索引算法分类（精确 vs 近似）、主流算法对比（Flat、HNSW、IVFFLAT、IVF-PQ、IVF_RABITQ），重点剖析 HNSW 的多层图结构原理与调优参数（m、ef_construction、ef_search），并对比 HNSW 与 IVFFLAT 的适用场景。文章还梳理了四类向量数据库选型（传统 DB 扩展、搜索引擎演进、原生专业库、云托管服务），以 SpringAI 面试平台项目为例，给出 PostgreSQL + pgvector 的选型理由：架构简单、百万级性能够用、事务一致性、SQL 混合查询便利。最后指出 MySQL 在向量支持上的滞后（9.0 才引入 VECTOR 类型但无 ANN 索引），强化 PostgreSQL 在 AI 时代的可扩展性优势。

💡 主要观点

- 暴力搜索在百万级向量下延迟达秒级，无法用于生产 RAG 系统。 全表遍历计算相似度的时间复杂度为 O(n)，100 万 1024 维向量单次查询需十亿次乘法运算，延迟不可接受。

ANN 近似检索以不到 5% 的召回率损失换取 100 倍以上的速度提升。 HNSW 等图索引将检索延迟降至毫秒级，是生产级 RAG 系统的核心基础设施。

HNSW 在百万级数据下综合表现最优，但内存消耗大；IVFFLAT 更适合千万级以上或内存受限场景。 HNSW 查询极快、召回率稳定，但需存储图连接指针；IVFFLAT 构建快、内存友好，但召回率略低且需定期重训聚类中心。

PostgreSQL + pgvector 是百万级 RAG 项目的首选方案，兼顾架构简洁与事务一致性。 无需引入额外组件，支持 HNSW 索引实现毫秒级检索，且向量数据与业务数据可在同一事务中管理，适合中小型项目。

MySQL 在向量支持上严重滞后，9.0 版本仅有 VECTOR 类型但无 ANN 索引。 MySQL 9.0 引入向量数据类型但仅支持暴力计算，生态成熟度远低于 pgvector，不适合生产级 RAG 场景。

💬 文章金句

- 用不到 5% 的召回率损失，换来 100 倍以上的速度提升——这就是索引的价值。

HNSW 的本质是近似最近邻（ANN）算法，意味着它为了追求极致速度，无法保证 100% 的召回率。但在实践中，通过调整参数，召回率可以达到 99% 以上，对于 RAG 应用完全足够。
PostgreSQL 最大的优势，也是它在 AI 时代甩开对手的'王牌'，就是其强大的可扩展性。

📊 文章信息

AI 初评：86

来源：dbaplus社群

作者：dbaplus社群

分类：人工智能

语言：中文

阅读时间：26 分钟

字数：6416

标签： RAG, 向量数据库, HNSW, pgvector, AI 工程实践

阅读完整文章

RAG 不用向量数据库，用 MySQL 硬扛？暴力搜索的巨坑……

🤖 問 AI