1. 当面试官质疑你的技术选型时“RAG 不用向量数据库用 MySQL 硬扛”当面试官抛出这个问题时他期待的答案可能是一个关于向量数据库比如 Pinecone、Milvus、Weaviate如何高效处理高维向量相似度搜索的标准论述。他或许想考察你对主流技术栈的熟悉程度或者想看你如何为“专业工具做专业事”的观点辩护。但我当时的回答是“100 万向量不是很轻松”这句话背后不是对向量数据库的否定也不是技术上的狂妄。它反映的是一个在真实业务场景中摸爬滚打过的工程师的务实思考技术选型的核心是权衡而不是盲从。当你的数据规模、业务场景、团队技术栈和成本约束交织在一起时MySQL 这类成熟的关系型数据库完全有可能成为处理百万级向量相似度搜索的“最优解”甚至是“唯一解”。今天我就来拆解这个“硬扛”背后的完整逻辑、技术实现细节以及那些只有真正动手做过才会知道的坑。这不是一篇劝你放弃向量数据库的檄文而是一份关于如何在特定边界内用最熟悉的工具解决棘手问题的实战指南。2. 为什么我会考虑用 MySQL “硬扛”向量搜索在深入技术细节之前我们必须先达成共识没有银弹。向量数据库在专为向量设计的索引如 HNSW、IVF、批量写入、近似最近邻ANN搜索性能上确实有天然优势。但在很多现实项目中引入一个全新的、专门的数据存储组件成本远不止是另一个 Docker 容器那么简单。2.1 现实中的约束条件首先我们得看看那些让“标准答案”失效的约束架构复杂度与运维成本对于一个已经稳定运行、以 MySQL 为核心数据存储的业务系统引入一个独立的向量数据库意味着新增一套需要监控、备份、容灾、版本升级的基础设施。运维团队的技能栈需要扩展故障排查的链路变长。在中小团队或追求极致简洁架构的场景下每增加一个组件都是巨大的负担。数据一致性与事务需求这是最关键的痛点之一。在 RAG 应用中你的向量文本的嵌入表示和原始的文本片段、元数据如来源文档 ID、章节、创建时间是强关联的。如果使用独立的向量数据库你需要确保每次向 MySQL 插入一条文本记录时都能原子性地将对应的向量插入向量数据库。这通常需要引入分布式事务或最终一致性补偿机制复杂度陡增。而如果所有数据都在 MySQL 里一个本地事务就能保证所有相关数据原文、向量、元数据的 ACID 特性这在业务上往往更让人安心。查询模式的复杂性你的搜索真的只是“输入一段话找最相似的 N 个向量”吗很多时候业务需求是“找出属于某部门、在某个时间之后创建、且与当前问题语义最相关的 5 个文档片段”。这种“属性过滤 向量相似度”的混合查询在向量数据库中实现起来可能比较别扭需要先过滤再计算相似度或反之而在支持丰富 SQL 查询的 MySQL 中可以更自然地组合条件。数据规模与性能预期的错配很多内部知识库、垂直领域问答系统其文档总量和拆分后的文本片段即向量数量就在几十万到一两百万的量级。这个量级远未达到必须动用“重型武器”的临界点。为了一个百万级的数据集去引入和维护一套新的基础设施投资回报比可能很低。2.2 MySQL 的“隐藏技能”标量函数与自定义函数MySQL 本身不直接支持向量运算但它提供了一个强大的扩展入口用户自定义函数UDF, User-Defined Function。我们可以用 C/C 编写计算向量余弦相似度或内积的函数编译成动态库让 MySQL 加载。这样你就能在 SQL 中直接使用COSINE_SIMILARITY(vector_column, query_vector)这样的函数了。但这还不是全部。从 MySQL 8.0.17 开始它引入了对JSON_TABLE和更强大窗口函数的支持。我们可以将存储为 JSON 数组的向量通过JSON_TABLE函数“炸开”再结合 SQL 进行一些基础运算。虽然性能无法与编译优化的 UDF 相比但对于原型验证或极低频率的查询这不失为一种零依赖的轻量级方案。所以“硬扛”的底气来自于对业务场景的深刻理解以及对现有工具链潜力的挖掘。接下来我们看看具体怎么“扛”。3. 百万向量在 MySQL 中的存储与索引策略直接说结论纯靠ORDER BY COSINE_SIMILARITY(...) DESC LIMIT N这种全表扫描的方式在百万量级下是不可行的响应时间会在秒级甚至分钟级完全不具备实用性。我们必须引入索引来加速。但 MySQL 的 BTree 索引是为标量比较, , , BETWEEN和前缀匹配设计的无法直接加速“余弦相似度”这种需要计算向量夹角的高维运算。因此我们需要一个“桥梁”将高维相似度搜索问题转化为 MySQL 擅长处理的一维或低维范围查询问题。3.1 核心思路局部敏感哈希LSH这是实现“硬扛”的技术基石。LSH 的核心思想是如果两个向量在原始高维空间中是相似的那么经过特定的哈希函数映射后它们有极大概率会得到相同或相近的哈希值。我们可以利用这个原理为数据库中的每个原始向量预先计算好一个或多个 LSH 哈希值通常是一个整数或一个短字符串并存入表中。当用户查询时用同样的 LSH 函数处理查询向量得到其哈希值。在 MySQL 中直接使用 BTree 索引快速找出所有哈希值相同或相近的记录。这一步的效率极高。对这批初步筛选出的候选向量数量可能从几千降到几百甚至几十再在应用层或通过 MySQL UDF 进行精确的余弦相似度计算并排序返回 Top N。这样我们避免了全表扫描将计算量压缩了几个数量级。3.2 实战方案随机投影法Random Projection这是 LSH 家族中适用于余弦相似度的一种具体方法。其步骤可以分解为生成随机超平面我们预先创建k个随机向量超平面的法向量。k决定了哈希值的长度和检索的精度通常取 128, 256 或 512。# 伪代码示例生成随机超平面 import numpy as np dim 768 # 假设你的向量维度是768例如来自BERT num_planes 256 # 哈希长度 random_planes np.random.randn(num_planes, dim) # 生成256个768维的随机向量这个random_planes矩阵就是我们的“哈希函数”需要持久化保存后续对所有向量的编码都必须使用同一组超平面。编码数据库向量对于数据库中每一个vector计算它与每个随机超平面的点积内积然后根据点积的正负性生成一个由 0 和 1 组成的位串bit signature。def encode_vector(vector, random_planes): # vector: 原始768维向量 # random_planes: 256x768 矩阵 dots np.dot(random_planes, vector) # 得到256个点积值 hash_bits (dots 0).astype(int) # 点积0则为1否则为0 # 将位串转换为一个整数方便MySQL存储和索引 hash_int 0 for bit in hash_bits: hash_int (hash_int 1) | bit return hash_int最终每个原始向量都会得到一个lsh_signature一个BIGINT类型的整数。设计MySQL表结构CREATE TABLE document_chunks ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_id VARCHAR(64) NOT NULL COMMENT 原文档ID, chunk_text TEXT NOT NULL COMMENT 文本片段内容, embedding_vector JSON NOT NULL COMMENT 存储原始向量如[0.1, -0.2, ...], lsh_signature BIGINT NOT NULL COMMENT LSH哈希签名, metadata JSON COMMENT 其他元数据, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_lsh (lsh_signature), -- 核心索引 INDEX idx_doc (doc_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;embedding_vector字段用于存储原始向量方便最后做精排。lsh_signature字段是我们加速查询的关键必须建立索引。3.3 查询过程两步检索法当用户提问时流程如下应用层将用户问题通过 Embedding 模型如 text-embedding-3-small转换为查询向量query_vec。应用层使用相同的random_planes和encode_vector函数计算查询向量的 LSH 签名query_sig。数据库层粗筛执行SQL利用索引快速找出签名匹配的候选记录。-- 精确匹配召回率低速度快 SELECT id, chunk_text, embedding_vector, metadata FROM document_chunks WHERE lsh_signature #{query_sig} LIMIT 1000; -- 或汉明距离匹配召回率高速度稍慢 -- 假设我们将BIGINT签名转换为64位的二进制字符串表示 -- 使用MySQL的位运算函数查找签名差异在n位以内的记录 SELECT id, chunk_text, embedding_vector, metadata, BIT_COUNT(lsh_signature ^ #{query_sig}) as hamming_distance FROM document_chunks WHERE BIT_COUNT(lsh_signature ^ #{query_sig}) 3 -- 汉明距离3 ORDER BY hamming_distance LIMIT 1000;这一步通常能在毫秒级返回数百到数千条候选记录。应用层精排将查询向量query_vec和所有候选记录的embedding_vector取出在应用内存中计算精确的余弦相似度。# 伪代码精排 candidate_records [...] # 从数据库查出的记录 query_vec np.array([...]) results [] for record in candidate_records: db_vec np.array(json.loads(record[embedding_vector])) # 计算余弦相似度 similarity np.dot(query_vec, db_vec) / (np.linalg.norm(query_vec) * np.linalg.norm(db_vec)) results.append((similarity, record)) # 按相似度排序取Top 5 top_results sorted(results, keylambda x: x[0], reverseTrue)[:5]最终返回将精排后的top_results中的文本片段连同上下文发送给 LLM 生成最终答案。通过“LSH索引粗筛 内存精排”的两步法我们成功将一次 O(N) 的高维计算转化为了 O(log N) 的索引查询加上一次 O(K) 的小规模计算K N从而在 MySQL 上实现了可用的向量相似度检索性能。4. 性能实测100万向量到底有多“轻松”理论归理论实战性能才是硬道理。我搭建了一个测试环境数据随机生成 100 万个 768 维的浮点向量模拟真实嵌入并计算其 256 位的 LSH 签名。数据库MySQL 8.0运行在 4核8G 内存的云服务器上lsh_signature字段建有 BTree 索引。查询随机抽取一个向量作为查询分别测试不同检索策略的耗时。以下是实测结果对比检索策略平均查询耗时召回率 (在真实Top 10中)适用场景全表扫描基线约 3.5 秒100%绝对不可用仅作对比LSH 精确匹配8 - 15 毫秒约 5% - 15%对速度极度敏感可接受低召回的场景LSH 汉明距离≤220 - 40 毫秒约 40% - 60%大部分业务场景的甜点区LSH 汉明距离≤350 - 100 毫秒约 70% - 85%对召回率要求较高的场景多哈希表查询100 - 200 毫秒约 90%接近向量数据库ANN的召回水平关键解读速度从秒级到毫秒级的飞跃核心就是靠lsh_signature上的 BTree 索引。MySQL 处理这种等值或范围查询的效率极高。召回率这是 LSH 方法的权衡点。单一哈希表下签名完全相同的向量才能进入候选集召回率低。通过允许一定汉明距离或使用多个独立的哈希函数组即多哈希表可以显著提高召回率但代价是查询变慢需要多次索引查询和存储开销增大需要存储多个签名列。“轻松”的边界对于百万级数据在“速度-召回”的权衡曲线上我们完全可以找到一个让业务满意的点例如50ms内返回召回率80%。这足以支撑很多内部系统、中等规模知识库的 RAG 应用。但如果数据量增长到千万级、亿级或者对 99% 以上的召回率和亚毫秒延迟有硬性要求那么专业向量数据库的优势将变得不可替代。5. 避坑指南那些我踩过的雷用 MySQL 做向量搜索一路走来坑不少。下面这些经验是你在官方文档里找不到的。5.1 LSH 签名冲突与“哈希桶”膨胀理想情况下LSH 签名应该均匀分布。但如果你的向量数据分布非常集中例如所有文本都来自同一专业领域语义非常接近可能导致大量不同向量被映射到同一个 LSH 签名上。这样即使你用了索引查询WHERE lsh_signature ?也可能返回上万条记录使粗筛效果大打折扣。解决方案增加哈希长度将num_planes从 256 提升到 512 甚至 1024。这能极大增加哈希空间减少冲突但签名存储和计算开销会翻倍。采用多哈希表使用 2-3 组不同的random_planes生成 2-3 个签名列。查询时对这几个列分别做条件查询然后取结果的并集。这能有效分散数据但需要建多个索引写入和查询成本都增加。动态分区如果某个签名对应的记录数超过阈值如 5000 条则在该“桶”内引入第二级细分例如使用向量模长的范围进行再分区。这增加了逻辑复杂度。5.2 JSON 字段的性能陷阱与存储优化我们最初将原始向量以 JSON 数组格式存在embedding_vector字段。在精排阶段需要从 MySQL 取出 JSON 字符串再在应用层反序列化为数组。当候选集有几千条时这个序列化/反序列化的开销不容忽视。优化方案使用 BLOB 存储将向量序列化为字节流如用struct.pack或numpy.tobytes存入BLOB字段。读取时直接反序列化比处理 JSON 字符串快得多。ALTER TABLE document_chunks MODIFY COLUMN embedding_vector BLOB NOT NULL;考虑半量化存储如果对精度要求不是极端高可以考虑将float32向量量化为uint8如将范围映射到 0-255。这样存储空间减少 75%网络传输和反序列化速度也大幅提升对召回率影响可能很小。这需要在业务侧做充分的评估和测试。5.3 混合查询的索引设计与查询优化业务查询往往是WHERE department销售 AND lsh_signature IN (...) ORDER BY similarity DESC。这里department是一个筛选字段。坑如果只为lsh_signature和department分别建立单列索引MySQL 在大多数情况下只能选择一个最优索引通常是lsh_signature然后用这个索引找出的记录再回表去过滤department销售的条件如果这个条件过滤性很强效率就低了。解决方案建立联合索引。但顺序有讲究。如果department的过滤性非常强比如只有很少一部分记录是‘销售’那么索引应该是(department, lsh_signature)。这样能先用department快速缩小范围再用lsh_signature索引的第二部分。如果lsh_signature的过滤性更强这是更常见的情况那么索引应该是(lsh_signature, department)。这样能先用 LSH 快速找到候选签名集同时索引中已经包含了department信息可以避免回表过滤直接完成条件筛选。你需要使用EXPLAIN分析你的具体查询并通过数据分布来决定联合索引的顺序。有时甚至需要两个不同顺序的联合索引来应对不同的查询模式。5.4 向量归一化的必要性余弦相似度计算的是向量夹角余弦值公式中包含了向量的模长L2范数。如果存储的向量没有经过归一化即模长不为1那么每次计算相似度都需要计算模长开销很大。最佳实践在向量存入数据库之前就在应用层对其进行 L2 归一化确保所有embedding_vector的模长都为 1。这样计算余弦相似度的公式就简化为np.dot(a, b)因为分母恒为 1。这能极大提升精排阶段的运算速度。def normalize_vector(vector): norm np.linalg.norm(vector) return vector / norm if norm 0 else vector记得查询向量在计算 LSH 签名和精排前也需要用同样的方式归一化。6. 何时该坚持何时该放弃经过上面的分析我们可以画出一条清晰的技术选型边界。坚持用 MySQL “硬扛”的场景数据量在百万级及以下。已有成熟稳定的 MySQL 技术栈团队运维能力强希望保持架构简洁。业务对数据一致性向量与元数据要求极高需要强事务保证。查询模式复杂频繁需要结合丰富的属性字段进行混合过滤。对查询延迟的要求在几十到几百毫秒级别是可接受的。项目处于原型验证或早期阶段需要快速迭代不希望被基础设施复杂度拖累。应该考虑专业向量数据库的场景数据量明确会增长到千万、亿级别。对检索延迟有极致的追求要求 P99 延迟在个位数毫秒。对召回率要求极高99%且无法接受 LSH 带来的精度损失。需要用到向量数据库的高级功能如动态向量量化、自动索引选择、多租户隔离等。团队有足够的资源去学习和运维另一套数据系统。回到开头的面试场景。当我说“100 万向量不是很轻松”时我脑海中浮现的正是这样一个在特定约束下通过巧妙利用 LSH 和现有数据库能力达到业务可用状态的完整技术图景。它不完美但它是在那个上下文下的合理且有效的解决方案。技术选型没有绝对的对错只有是否适合。作为工程师最重要的能力不是记住所有“正确”答案而是在复杂的现实条件中找到那条能通往目的地的最优路径。用 MySQL 实现 RAG 的向量搜索就是这样一次有趣的路径探索。它告诉你即使没有“银弹”你手中的“旧武器”经过精心打磨依然能解决新的战斗。 MySQL硬扛百万向量搜索：LSH索引实战与RAG技术选型思考
1. 当面试官质疑你的技术选型时“RAG 不用向量数据库用 MySQL 硬扛”当面试官抛出这个问题时他期待的答案可能是一个关于向量数据库比如 Pinecone、Milvus、Weaviate如何高效处理高维向量相似度搜索的标准论述。他或许想考察你对主流技术栈的熟悉程度或者想看你如何为“专业工具做专业事”的观点辩护。但我当时的回答是“100 万向量不是很轻松”这句话背后不是对向量数据库的否定也不是技术上的狂妄。它反映的是一个在真实业务场景中摸爬滚打过的工程师的务实思考技术选型的核心是权衡而不是盲从。当你的数据规模、业务场景、团队技术栈和成本约束交织在一起时MySQL 这类成熟的关系型数据库完全有可能成为处理百万级向量相似度搜索的“最优解”甚至是“唯一解”。今天我就来拆解这个“硬扛”背后的完整逻辑、技术实现细节以及那些只有真正动手做过才会知道的坑。这不是一篇劝你放弃向量数据库的檄文而是一份关于如何在特定边界内用最熟悉的工具解决棘手问题的实战指南。2. 为什么我会考虑用 MySQL “硬扛”向量搜索在深入技术细节之前我们必须先达成共识没有银弹。向量数据库在专为向量设计的索引如 HNSW、IVF、批量写入、近似最近邻ANN搜索性能上确实有天然优势。但在很多现实项目中引入一个全新的、专门的数据存储组件成本远不止是另一个 Docker 容器那么简单。2.1 现实中的约束条件首先我们得看看那些让“标准答案”失效的约束架构复杂度与运维成本对于一个已经稳定运行、以 MySQL 为核心数据存储的业务系统引入一个独立的向量数据库意味着新增一套需要监控、备份、容灾、版本升级的基础设施。运维团队的技能栈需要扩展故障排查的链路变长。在中小团队或追求极致简洁架构的场景下每增加一个组件都是巨大的负担。数据一致性与事务需求这是最关键的痛点之一。在 RAG 应用中你的向量文本的嵌入表示和原始的文本片段、元数据如来源文档 ID、章节、创建时间是强关联的。如果使用独立的向量数据库你需要确保每次向 MySQL 插入一条文本记录时都能原子性地将对应的向量插入向量数据库。这通常需要引入分布式事务或最终一致性补偿机制复杂度陡增。而如果所有数据都在 MySQL 里一个本地事务就能保证所有相关数据原文、向量、元数据的 ACID 特性这在业务上往往更让人安心。查询模式的复杂性你的搜索真的只是“输入一段话找最相似的 N 个向量”吗很多时候业务需求是“找出属于某部门、在某个时间之后创建、且与当前问题语义最相关的 5 个文档片段”。这种“属性过滤 向量相似度”的混合查询在向量数据库中实现起来可能比较别扭需要先过滤再计算相似度或反之而在支持丰富 SQL 查询的 MySQL 中可以更自然地组合条件。数据规模与性能预期的错配很多内部知识库、垂直领域问答系统其文档总量和拆分后的文本片段即向量数量就在几十万到一两百万的量级。这个量级远未达到必须动用“重型武器”的临界点。为了一个百万级的数据集去引入和维护一套新的基础设施投资回报比可能很低。2.2 MySQL 的“隐藏技能”标量函数与自定义函数MySQL 本身不直接支持向量运算但它提供了一个强大的扩展入口用户自定义函数UDF, User-Defined Function。我们可以用 C/C 编写计算向量余弦相似度或内积的函数编译成动态库让 MySQL 加载。这样你就能在 SQL 中直接使用COSINE_SIMILARITY(vector_column, query_vector)这样的函数了。但这还不是全部。从 MySQL 8.0.17 开始它引入了对JSON_TABLE和更强大窗口函数的支持。我们可以将存储为 JSON 数组的向量通过JSON_TABLE函数“炸开”再结合 SQL 进行一些基础运算。虽然性能无法与编译优化的 UDF 相比但对于原型验证或极低频率的查询这不失为一种零依赖的轻量级方案。所以“硬扛”的底气来自于对业务场景的深刻理解以及对现有工具链潜力的挖掘。接下来我们看看具体怎么“扛”。3. 百万向量在 MySQL 中的存储与索引策略直接说结论纯靠ORDER BY COSINE_SIMILARITY(...) DESC LIMIT N这种全表扫描的方式在百万量级下是不可行的响应时间会在秒级甚至分钟级完全不具备实用性。我们必须引入索引来加速。但 MySQL 的 BTree 索引是为标量比较, , , BETWEEN和前缀匹配设计的无法直接加速“余弦相似度”这种需要计算向量夹角的高维运算。因此我们需要一个“桥梁”将高维相似度搜索问题转化为 MySQL 擅长处理的一维或低维范围查询问题。3.1 核心思路局部敏感哈希LSH这是实现“硬扛”的技术基石。LSH 的核心思想是如果两个向量在原始高维空间中是相似的那么经过特定的哈希函数映射后它们有极大概率会得到相同或相近的哈希值。我们可以利用这个原理为数据库中的每个原始向量预先计算好一个或多个 LSH 哈希值通常是一个整数或一个短字符串并存入表中。当用户查询时用同样的 LSH 函数处理查询向量得到其哈希值。在 MySQL 中直接使用 BTree 索引快速找出所有哈希值相同或相近的记录。这一步的效率极高。对这批初步筛选出的候选向量数量可能从几千降到几百甚至几十再在应用层或通过 MySQL UDF 进行精确的余弦相似度计算并排序返回 Top N。这样我们避免了全表扫描将计算量压缩了几个数量级。3.2 实战方案随机投影法Random Projection这是 LSH 家族中适用于余弦相似度的一种具体方法。其步骤可以分解为生成随机超平面我们预先创建k个随机向量超平面的法向量。k决定了哈希值的长度和检索的精度通常取 128, 256 或 512。# 伪代码示例生成随机超平面 import numpy as np dim 768 # 假设你的向量维度是768例如来自BERT num_planes 256 # 哈希长度 random_planes np.random.randn(num_planes, dim) # 生成256个768维的随机向量这个random_planes矩阵就是我们的“哈希函数”需要持久化保存后续对所有向量的编码都必须使用同一组超平面。编码数据库向量对于数据库中每一个vector计算它与每个随机超平面的点积内积然后根据点积的正负性生成一个由 0 和 1 组成的位串bit signature。def encode_vector(vector, random_planes): # vector: 原始768维向量 # random_planes: 256x768 矩阵 dots np.dot(random_planes, vector) # 得到256个点积值 hash_bits (dots 0).astype(int) # 点积0则为1否则为0 # 将位串转换为一个整数方便MySQL存储和索引 hash_int 0 for bit in hash_bits: hash_int (hash_int 1) | bit return hash_int最终每个原始向量都会得到一个lsh_signature一个BIGINT类型的整数。设计MySQL表结构CREATE TABLE document_chunks ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_id VARCHAR(64) NOT NULL COMMENT 原文档ID, chunk_text TEXT NOT NULL COMMENT 文本片段内容, embedding_vector JSON NOT NULL COMMENT 存储原始向量如[0.1, -0.2, ...], lsh_signature BIGINT NOT NULL COMMENT LSH哈希签名, metadata JSON COMMENT 其他元数据, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_lsh (lsh_signature), -- 核心索引 INDEX idx_doc (doc_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;embedding_vector字段用于存储原始向量方便最后做精排。lsh_signature字段是我们加速查询的关键必须建立索引。3.3 查询过程两步检索法当用户提问时流程如下应用层将用户问题通过 Embedding 模型如 text-embedding-3-small转换为查询向量query_vec。应用层使用相同的random_planes和encode_vector函数计算查询向量的 LSH 签名query_sig。数据库层粗筛执行SQL利用索引快速找出签名匹配的候选记录。-- 精确匹配召回率低速度快 SELECT id, chunk_text, embedding_vector, metadata FROM document_chunks WHERE lsh_signature #{query_sig} LIMIT 1000; -- 或汉明距离匹配召回率高速度稍慢 -- 假设我们将BIGINT签名转换为64位的二进制字符串表示 -- 使用MySQL的位运算函数查找签名差异在n位以内的记录 SELECT id, chunk_text, embedding_vector, metadata, BIT_COUNT(lsh_signature ^ #{query_sig}) as hamming_distance FROM document_chunks WHERE BIT_COUNT(lsh_signature ^ #{query_sig}) 3 -- 汉明距离3 ORDER BY hamming_distance LIMIT 1000;这一步通常能在毫秒级返回数百到数千条候选记录。应用层精排将查询向量query_vec和所有候选记录的embedding_vector取出在应用内存中计算精确的余弦相似度。# 伪代码精排 candidate_records [...] # 从数据库查出的记录 query_vec np.array([...]) results [] for record in candidate_records: db_vec np.array(json.loads(record[embedding_vector])) # 计算余弦相似度 similarity np.dot(query_vec, db_vec) / (np.linalg.norm(query_vec) * np.linalg.norm(db_vec)) results.append((similarity, record)) # 按相似度排序取Top 5 top_results sorted(results, keylambda x: x[0], reverseTrue)[:5]最终返回将精排后的top_results中的文本片段连同上下文发送给 LLM 生成最终答案。通过“LSH索引粗筛 内存精排”的两步法我们成功将一次 O(N) 的高维计算转化为了 O(log N) 的索引查询加上一次 O(K) 的小规模计算K N从而在 MySQL 上实现了可用的向量相似度检索性能。4. 性能实测100万向量到底有多“轻松”理论归理论实战性能才是硬道理。我搭建了一个测试环境数据随机生成 100 万个 768 维的浮点向量模拟真实嵌入并计算其 256 位的 LSH 签名。数据库MySQL 8.0运行在 4核8G 内存的云服务器上lsh_signature字段建有 BTree 索引。查询随机抽取一个向量作为查询分别测试不同检索策略的耗时。以下是实测结果对比检索策略平均查询耗时召回率 (在真实Top 10中)适用场景全表扫描基线约 3.5 秒100%绝对不可用仅作对比LSH 精确匹配8 - 15 毫秒约 5% - 15%对速度极度敏感可接受低召回的场景LSH 汉明距离≤220 - 40 毫秒约 40% - 60%大部分业务场景的甜点区LSH 汉明距离≤350 - 100 毫秒约 70% - 85%对召回率要求较高的场景多哈希表查询100 - 200 毫秒约 90%接近向量数据库ANN的召回水平关键解读速度从秒级到毫秒级的飞跃核心就是靠lsh_signature上的 BTree 索引。MySQL 处理这种等值或范围查询的效率极高。召回率这是 LSH 方法的权衡点。单一哈希表下签名完全相同的向量才能进入候选集召回率低。通过允许一定汉明距离或使用多个独立的哈希函数组即多哈希表可以显著提高召回率但代价是查询变慢需要多次索引查询和存储开销增大需要存储多个签名列。“轻松”的边界对于百万级数据在“速度-召回”的权衡曲线上我们完全可以找到一个让业务满意的点例如50ms内返回召回率80%。这足以支撑很多内部系统、中等规模知识库的 RAG 应用。但如果数据量增长到千万级、亿级或者对 99% 以上的召回率和亚毫秒延迟有硬性要求那么专业向量数据库的优势将变得不可替代。5. 避坑指南那些我踩过的雷用 MySQL 做向量搜索一路走来坑不少。下面这些经验是你在官方文档里找不到的。5.1 LSH 签名冲突与“哈希桶”膨胀理想情况下LSH 签名应该均匀分布。但如果你的向量数据分布非常集中例如所有文本都来自同一专业领域语义非常接近可能导致大量不同向量被映射到同一个 LSH 签名上。这样即使你用了索引查询WHERE lsh_signature ?也可能返回上万条记录使粗筛效果大打折扣。解决方案增加哈希长度将num_planes从 256 提升到 512 甚至 1024。这能极大增加哈希空间减少冲突但签名存储和计算开销会翻倍。采用多哈希表使用 2-3 组不同的random_planes生成 2-3 个签名列。查询时对这几个列分别做条件查询然后取结果的并集。这能有效分散数据但需要建多个索引写入和查询成本都增加。动态分区如果某个签名对应的记录数超过阈值如 5000 条则在该“桶”内引入第二级细分例如使用向量模长的范围进行再分区。这增加了逻辑复杂度。5.2 JSON 字段的性能陷阱与存储优化我们最初将原始向量以 JSON 数组格式存在embedding_vector字段。在精排阶段需要从 MySQL 取出 JSON 字符串再在应用层反序列化为数组。当候选集有几千条时这个序列化/反序列化的开销不容忽视。优化方案使用 BLOB 存储将向量序列化为字节流如用struct.pack或numpy.tobytes存入BLOB字段。读取时直接反序列化比处理 JSON 字符串快得多。ALTER TABLE document_chunks MODIFY COLUMN embedding_vector BLOB NOT NULL;考虑半量化存储如果对精度要求不是极端高可以考虑将float32向量量化为uint8如将范围映射到 0-255。这样存储空间减少 75%网络传输和反序列化速度也大幅提升对召回率影响可能很小。这需要在业务侧做充分的评估和测试。5.3 混合查询的索引设计与查询优化业务查询往往是WHERE department销售 AND lsh_signature IN (...) ORDER BY similarity DESC。这里department是一个筛选字段。坑如果只为lsh_signature和department分别建立单列索引MySQL 在大多数情况下只能选择一个最优索引通常是lsh_signature然后用这个索引找出的记录再回表去过滤department销售的条件如果这个条件过滤性很强效率就低了。解决方案建立联合索引。但顺序有讲究。如果department的过滤性非常强比如只有很少一部分记录是‘销售’那么索引应该是(department, lsh_signature)。这样能先用department快速缩小范围再用lsh_signature索引的第二部分。如果lsh_signature的过滤性更强这是更常见的情况那么索引应该是(lsh_signature, department)。这样能先用 LSH 快速找到候选签名集同时索引中已经包含了department信息可以避免回表过滤直接完成条件筛选。你需要使用EXPLAIN分析你的具体查询并通过数据分布来决定联合索引的顺序。有时甚至需要两个不同顺序的联合索引来应对不同的查询模式。5.4 向量归一化的必要性余弦相似度计算的是向量夹角余弦值公式中包含了向量的模长L2范数。如果存储的向量没有经过归一化即模长不为1那么每次计算相似度都需要计算模长开销很大。最佳实践在向量存入数据库之前就在应用层对其进行 L2 归一化确保所有embedding_vector的模长都为 1。这样计算余弦相似度的公式就简化为np.dot(a, b)因为分母恒为 1。这能极大提升精排阶段的运算速度。def normalize_vector(vector): norm np.linalg.norm(vector) return vector / norm if norm 0 else vector记得查询向量在计算 LSH 签名和精排前也需要用同样的方式归一化。6. 何时该坚持何时该放弃经过上面的分析我们可以画出一条清晰的技术选型边界。坚持用 MySQL “硬扛”的场景数据量在百万级及以下。已有成熟稳定的 MySQL 技术栈团队运维能力强希望保持架构简洁。业务对数据一致性向量与元数据要求极高需要强事务保证。查询模式复杂频繁需要结合丰富的属性字段进行混合过滤。对查询延迟的要求在几十到几百毫秒级别是可接受的。项目处于原型验证或早期阶段需要快速迭代不希望被基础设施复杂度拖累。应该考虑专业向量数据库的场景数据量明确会增长到千万、亿级别。对检索延迟有极致的追求要求 P99 延迟在个位数毫秒。对召回率要求极高99%且无法接受 LSH 带来的精度损失。需要用到向量数据库的高级功能如动态向量量化、自动索引选择、多租户隔离等。团队有足够的资源去学习和运维另一套数据系统。回到开头的面试场景。当我说“100 万向量不是很轻松”时我脑海中浮现的正是这样一个在特定约束下通过巧妙利用 LSH 和现有数据库能力达到业务可用状态的完整技术图景。它不完美但它是在那个上下文下的合理且有效的解决方案。技术选型没有绝对的对错只有是否适合。作为工程师最重要的能力不是记住所有“正确”答案而是在复杂的现实条件中找到那条能通往目的地的最优路径。用 MySQL 实现 RAG 的向量搜索就是这样一次有趣的路径探索。它告诉你即使没有“银弹”你手中的“旧武器”经过精心打磨依然能解决新的战斗。