已有 MySQL 业务系统如何部署向量检索能力

一、部署概述

本文讨论的部署对象，是在一个已经稳定运行的 MySQL 业务系统之上，新增“向量检索”这一能力模块，使业务数据库中的非结构化文本数据（用户评论、产品文档、客服对话等）能够被大语言模型与检索增强生成（RAG）流程调用。部署完成后应达到的效果是：业务系统可以在原有 MySQL 架构内完成文本向量化存储、近似最近邻检索与相似度查询，并向大模型应用提供语义召回结果，而不必额外引入独立的向量数据库集群。

适合阅读本文的读者包括：负责业务系统演进的开发者、承担数据库与服务上线的运维人员、参与 RAG 应用落地的架构师，以及需要评估改造范围与资源投入的技术负责人。

在部署前，需要先理解几个基本背景：一是业务数据仍以结构化数据为主，向量检索是增量能力而非替代能力；二是向量检索依赖文本向量化模型，模型可能运行在应用侧或独立的推理服务中；三是检索请求通常来自应用层而非终端用户直连，因此需要规划好服务边界与访问控制；四是不同 MySQL 版本的向量能力差异明显，部署路径需要按版本分流。

二、部署场景与版本选型

向量检索能力的部署通常出现在以下场景：为智能客服构建知识召回链路；为内容平台实现语义相似推荐；为文档系统提供自然语言问答入口；为工单系统做历史问题相似匹配。这些场景的共同点是查询意图是“语义相近”，而非“关键词命中”，传统 LIKE 与全文索引难以满足。

部署路径首先取决于现有 MySQL 版本：

版本情况	部署路径	说明
支持原生向量类型与向量索引的较新版本	原生方案	直接使用原生向量类型与近似最近邻索引，检索在数据库内完成
存量低版本（如 8.0.x）	兼容方案	以字符串或二进制列存储向量，配合自定义函数计算相似度，检索以扫描为主

选型时需要评估：数据规模与检索频次决定兼容方案是否可接受；是否有条件做版本升级或新建实例；应用侧是否已有稳定的向量化模型服务。对于数据量较大、检索并发较高的场景，优先规划原生方案；对于改造窗口有限、数据量可控的场景，可先用兼容方案完成能力上线，再规划平滑演进。

三、架构与组件拆解

部署中涉及的关键模块可拆为以下几层：

• 存储层：MySQL 实例承载原始业务表与向量数据。原生方案下向量作为独立列类型存储并建立索引；兼容方案下向量以字符串或二进制形式存放。
• 计算层：应用服务或独立推理服务负责调用文本向量化模型，将查询文本与入库文本转换为同维度向量。需保证入库与查询使用同一模型、同一维度、同一归一化方式。
• 检索层：原生方案由数据库索引完成近似最近邻检索；兼容方案由自定义函数在查询中计算距离并排序，必要时配合分区、过滤条件缩小扫描范围。
• 接入层：应用通过连接池访问数据库，检索接口应有超时、限流与降级策略，避免慢查询拖垮业务库。
• 运维层：包括慢查询日志、资源监控、备份恢复、权限管理与变更发布流程。

四、前置准备

部署前需完成以下准备：

1. 环境与权限：确认 MySQL 实例版本、可用磁盘空间与内存余量；为向量能力单独规划数据库账号，遵循最小权限原则，仅授予必要的读写与执行权限。
2. 资源规划：向量列会显著增加存储占用，需按“向量维度 × 数据条数 × 每条占用字节”估算容量，并预留索引构建期间的临时空间；检索属于计算密集型操作，需评估 CPU 与内存峰值。
3. 模型服务准备：确定向量化模型的部署方式（应用内嵌或独立服务）、向量维度、批量转换的并发度，并保证服务可水平扩展。
4. 数据准备：梳理需要向量化的文本字段，明确清洗规则（去噪、截断长度、统一编码），并设计增量更新策略，避免全量重算。
5. 网络与配置：确认应用与数据库之间的网络连通性、端口策略与加密传输方式；将连接地址、账号密钥放入配置中心或环境变量，避免硬编码。
6. 变更窗口：索引构建与批量向量化可能带来明显负载，应安排在低峰期并准备回滚方案。

五、部署流程

步骤一：环境初始化与实例确认

先核对实例版本与参数，确认目标能力可用；在测试环境完成同版本演练，保证开发、测试、生产环境的一致性。为向量相关表结构变更准备迁移脚本，脚本应可重复执行并记录版本号。

步骤二：表结构与存储设计

在业务表中新增向量列，或建立独立的向量扩展表，通过主键与业务表关联。独立扩展表便于按需重建索引与控制影响范围。示例如下（通用示意，非具体产品语法）：

-- 示意：新增向量扩展表
CREATE TABLE item_vector (
  item_id      BIGINT PRIMARY KEY,
  content_hash VARCHAR(64),
  embedding    VECTOR(768),
  updated_at   TIMESTAMP
);

步骤三：文本向量化与数据初始化

按批次读取文本、调用向量化服务、写回向量列。批处理需控制批次大小与并发，记录失败条目并支持断点续跑。初始化完成后校验条数与空值比例，抽样比对入库向量与查询向量的维度一致性。

步骤四：索引构建

原生方案下在向量列上创建近似最近邻索引，构建期间会占用较多资源，建议在低峰执行并监控进度。兼容方案下不建向量索引，而是通过业务过滤条件与分区裁剪降低扫描量，必要时为关联字段补充普通索引。

步骤五：应用接入与配置

在应用侧新增检索接口，流程为：接收查询文本→调用向量化服务→执行相似度检索→返回候选结果及相似度分值。关键配置项包括：连接池上限、查询超时、候选返回条数、相似度阈值、失败降级开关。配置应通过环境变量注入，不同环境使用不同取值。

步骤六：灰度与上线

先对小流量开放检索接口，观察响应时间与数据库负载；确认稳定后逐步放量。发布过程保留旧版本服务与旧配置，便于快速回滚。

六、上线验证

部署成功的判断依据包括：检索接口在约定超时内返回结果；返回结果的相似度分布符合预期，抽样人工核对语义相关性；数据库慢查询数量与 CPU、内存、连接数处于基线范围；日志中无持续报错；向量化服务成功率与积压量正常；备份任务可正常执行。建议准备一组固定查询集作为回归用例，每次变更后复跑比对。

七、常见问题与排查

• 检索结果相关性差：多为入库与查询使用了不同模型或不同归一化方式，需统一向量化链路并重算存量数据。
• 查询变慢：兼容方案下常见于扫描量过大，可通过增加过滤条件、分区、限制候选集缓解；原生方案下检查索引是否生效与是否发生全表扫描。
• 写入放大与存储增长：向量列占用超出预期，应复核维度与条数估算，清理无效数据并评估压缩与归档策略。
• 索引构建失败或超时：资源不足或并发写入冲突，应降低构建并发、扩大临时空间并在低峰重试。
• 连接被打满：检索请求未设超时或并发过高，需补充限流、超时与连接池上限配置。

八、运维与优化

上线后应持续关注四类工作：稳定性方面配置健康检查、慢查询告警与异常重启策略，检索链路设置超时与降级；安全方面坚持最小权限、密钥集中管理、传输加密与访问白名单，并保留审计日志；性能方面优化批量向量化的批大小与并发，合理设置候选条数与相似度阈值，热点数据可考虑缓存；成本方面按实际负载配置规格，定期治理闲置资源，对历史向量数据制定生命周期策略。版本升级、模型更换与表结构调整都应走灰度发布与回滚预案，确保业务库始终处于可控状态。

九、总结

在已有 MySQL 业务系统上部署向量检索，本质是一次“能力叠加”而非“架构替换”：先按版本确定原生或兼容路径，再完成资源规划、模型服务准备与数据初始化，随后按“建表—向量化—建索引—接应用—灰度上线”的顺序推进，最后以接口时延、结果相关性、数据库负载与日志指标完成验证，并通过监控告警、权限管理、容量评估与回滚预案保障长期稳定运行。