1. 向量数据库概述：从零认识这个新物种
说实话，我第一次听到「向量数据库」这个词时，脑子里冒出的第一个问题是：这玩意儿跟 MySQL 有什么区别？后来真正上手做项目，才明白它解决的是传统数据库搞不定的问题。
这一章，咱们就从最基础的概念开始，一步步拆解。
1.1 什么是向量？
向量，说白了就是一串数字。比如 [0.12, 0.45, -0.33, 0.78] 就是一个 4 维向量。在计算机眼里，任何东西都可以用向量表示——文字、图片、声音、用户行为，甚至你昨天在电商平台点过的商品。
举个例子。我习惯把「苹果」这个词转成向量，大概长这样：
[0.021, -0.045, 0.132, 0.078, -0.009, 0.211, ...] // 一共 768 个数字为什么是 768 个？因为常用的文本向量模型（比如 BGE、text2vec）默认输出 768 维。维度越高，能表达的信息越丰富，但计算量也越大。
你想想看，两个向量之间可以算「距离」。距离越近，代表它们越相似。比如「苹果」和「香蕉」的向量距离很近，而「苹果」和「汽车」的向量距离就很远。这就是向量搜索的核心逻辑。
1.2 什么是向量数据库？
向量数据库，就是专门用来存向量、搜向量的数据库。它不像 MySQL 那样按字段精确匹配，而是按「相似度」来查。
举个例子。你在电商平台搜「红色连衣裙」，传统数据库会去匹配商品标题里有没有这几个字。但向量数据库不一样——它把你的搜索词转成向量，然后去库里找所有跟这个向量「长得像」的商品。哪怕商品标题写的是「酒红色连衣长裙」，也能被召回。
我参与过一个推荐系统项目，早期用 Elasticsearch 做语义搜索，效果很差。后来换成向量数据库，召回率从 62% 直接跳到 89%。嗯，差距就是这么大。
目前主流的向量数据库有这些：
| 产品 | 类型 | 特点 |
|---|---|---|
| Milvus | 专用向量数据库 | 分布式、高可用、支持 GPU 加速 |
| Qdrant | 专用向量数据库 | Rust 编写、性能好、API 简洁 |
| Weaviate | 专用向量数据库 | 内置向量化模块、开箱即用 |
| pgvector | PostgreSQL 扩展 | 在传统数据库上加向量能力 |
| Redis Stack | 内存数据库扩展 | 低延迟、适合缓存场景 |
1.3 为什么需要向量数据库？
传统数据库处理精确匹配很在行，但遇到「模糊语义」就抓瞎了。我给你列几个真实场景：
- 语义搜索： 搜「怎么修电脑」，希望返回「电脑蓝屏怎么办」——关键词不匹配，但意思相近。
- 图片检索： 拿一张商品图去库里找同款——传统数据库根本没法比图片。
- 推荐系统： 根据用户历史行为，推荐相似商品——需要把用户行为转成向量。
- RAG（检索增强生成）： 大模型回答前，先去库里找相关文档——这是目前最火的应用。
说白了，凡是需要「找相似」的场景，向量数据库都比传统方案强一大截。
我记得有一次做客服问答系统，用户问「我的订单怎么还没到」，传统数据库匹配不到「物流查询」这个关键词。换成向量后，系统自动关联到物流状态查询模块，准确率从 55% 提升到 91%。
1.4 与传统数据库的对比
很多人问我：向量数据库能不能替代 MySQL？我的回答是：不能，也不应该。
它们各司其职。我画了一张对比表，你一看就明白：
| 对比维度 | 传统数据库（MySQL/PostgreSQL） | 向量数据库 |
|---|---|---|
| 查询方式 | 精确匹配、范围查询、模糊匹配 | 相似度搜索（最近邻） |
| 索引结构 | B+ 树、哈希索引 | HNSW、IVF、PQ |
| 适用场景 | 事务处理、结构化数据 | 非结构化数据、语义搜索 |
| 查询速度 | 毫秒级（精确匹配） | 毫秒级（近似搜索） |
| 数据一致性 | 强一致性（ACID） | 最终一致性为主 |
| 扩展性 | 垂直扩展为主 | 水平扩展为主 |
实际项目中，我习惯把两者结合使用。比如电商系统：商品信息（价格、库存、分类）存在 MySQL 里，商品描述向量存在向量数据库里。搜索时先向量检索出候选商品 ID，再去 MySQL 里拿详细信息。各取所长，才是最佳实践。
1.5 本章知识体系
下面这张图，帮你把本章的核心逻辑串起来：
嗯，这一章的内容就到这里。你只要记住三个核心点：向量是数字化的语义表达、向量数据库专为相似度搜索设计、它和传统数据库是互补关系。后面的章节，我们会一步步深入实战。