做了十几年数据相关的工作我见过太多次数据库选型现场变成辩论赛。后端说 MySQL 稳算法说得上向量库领导说 Redis 快DBA 说你们都在给我挖坑。最后谁赢往往不是最符合业务的而是嗓门最大的。我自己也经历过这种混乱期直到把这套选型的逻辑彻底捋顺才发现数据库选型这事情其实有迹可循它根本不是从数据库目录里挑一个顺眼的名字而是先把业务翻译成一系列数据需求再让数据库去匹配这些需求。关系型、文档型、键值型、向量型今天市面上叫得上名字的数据库少说也有几十种各有各的擅长也各有各的短板。这篇指南不打算给你排一个什么“十大数据库排行榜”而是把我这些年做架构选型时真正用到的思考框架、对比维度和落地经验全部摊开来讲尽量让新手也能顺着这套思路去做判断。我会从最基础的决策逻辑讲起再分别拆解关系型、文档型、键值型和这两年特别火的向量数据库最后聊一聊它们怎么组合使用。如果你正准备给新项目做技术选型或者想把现有系统里的某个存储换掉这篇文章应该能帮你省掉不少踩坑的时间。1. 选型真正的起点先别谈技术谈业务1.1 一个真实需求引发的思考我拿自己带过的一个实际项目举例。那是一个内容社区类产品用户要注册登录能发文章、写评论、点赞收藏后续还打算上一个“猜你喜欢”的推荐流。当时团队内部就炸了锅有人说用 MySQL有人说用 MongoDB还有人建议加 Redis搞推荐的同学说要上向量数据库。每个提议单独看都有道理但放在一起就变成了一团乱麻。问题出在哪大家把“选哪个数据库”当成了一个单选题但真实的业务需求从来不是一个维度。注册登录和文章发布涉及状态变更需要强一致性文章和评论这种内容天然是嵌套结构字段还可能随时增加点赞数、阅读量这种热数据要求极低的读写延迟推荐流又需要把文本或图片变成向量去算相似度。你把这几个诉求摆到桌面上答案其实是清楚的根本不是一个数据库能解决全部问题而是需要一组数据库各管一段。所以我后来在做选型时第一步永远不是打开数据库对比文档而是拿着业务需求一条条问下去直到把所有涉及数据存储和访问的诉求收集完整。1.2 四步需求拆解法我把这套收集和拆解的方法归纳成四步每次选型前对着走一遍基本能筛掉 80% 的错误选项。第一步看数据形态。你的数据是规规矩矩的表格状结构字段固定、关联明确还是嵌套很深的文档结构字段说变就变又或者只是一些临时性的键值对比如用户会话、验证码如果是高维向量比如几百维的文本 embedding那传统数据库压根不是你想不想用的问题而是根本查不动。这一步能把候选范围先圈出来。第二步看访问模式。业务是读多写少还是写多读少查询是固定几个模板比如按 ID 查、按用户查还是用户能随意组合任意字段做筛选固定模板适合 KV 数据库任意组合筛查就需要支持灵活查询的引擎。还要看你对查询延迟的容忍度100 毫秒可以接受还是必须压到 1 毫秒以下第三步看一致性和事务要求。账务、订单、库存这类场景数据错一笔都是事故必须支持严格的事务和强一致但像文章的点赞数、用户的浏览记录少一条或多一条几乎没有感知完全可以用弱一致换性能。很多选型翻车就是因为团队把不需要事务的场景硬塞进了支持事务的数据库把性能拖垮了反过来也有团队为了性能牺牲了事务最后对不上账。第四步看规模和演进。现在数据量是百万级但产品做起来之后三年可能到亿级这个量级对分库分表、水平扩展的要求完全不同。同时一定要评估团队的运维能力把 MySQL 玩明白已经需要一定功力了直接上一个分布式的 NewSQL团队没人啃得动最后可能连备份恢复都成问题。这四步跑完你会发现每种候选数据库适合什么、不适合什么已经清楚了一大半。后面几章我再逐个数据库类型来拆。2. 关系型数据库什么时候选它什么时候别硬选2.1 关系型数据库到底解决了什么问题关系型数据库是过去几十年最主流的存储方案MySQL、PostgreSQL、Oracle、SQL Server 都属于这一类。它的核心价值用一个词概括就是“确定性”。数据要遵守预先定义好的表结构每一列有明确类型表与表之间靠外键维护关系写入时通过事务保证要么全部成功要么全部失败。这套设计极其适合账务、订单、用户主数据这类业务因为数据的一致性容不得半点模糊。很多人会用“Excel 表格”来类比关系型数据库但更准确的类比是“带严格规章制度的 Excel”你只能在固定的列里填固定类型的内容当你要同时改两张表时数据库会确保要么两张表都改成功要么一张都不动。这种能力在金融、电商、ERP、CRM 这类场景里是刚需。关系型的第二个优势是 SQL。不要小看 SQL 这门语言的标准性它能让你用同一套语法完成建表、增删改查、多表关联、聚合统计而且无论是 MySQL 还是 PostgreSQL迁移到彼此的语法差异远小于换一个数据模型。团队成员普遍会写 SQL招聘成本也低。还有一个容易被低估的点是生态成熟度。关系型数据库的监控工具、备份方案、数据迁移工具、云服务托管版本都非常成熟。你踩过的坑网上基本都能搜到答案。这和用一些刚兴起的数据库是完全不一样的体验。2.2 MySQL还是PostgreSQL五个关键差异落到具体选型团队问得最多的就是 MySQL 和 PostgreSQL 怎么二选一。我直接给结论绝大多数场景这俩都能干但侧重点不同。我整理了一个对比表对比维度MySQLPostgreSQL默认事务隔离级别可重复读RR读已提交RCJSON 支持有 JSON 类型但查询能力有限jsonb 支持 GIN 索引查询能力很强全文检索一般需要额外插件内置 tsvector开箱即用复杂查询与窗口函数支持但部分语法较弱支持非常全面CTE 和窗口函数强大扩展性方向读写分离、分库分表方案多运维资料极其丰富既有分布式方案也有丰富外部数据源扩展FDW按我的实际使用经验PostgreSQL 更适合数据模型复杂、查询逻辑绕、需要处理半结构化大 JSON 的业务MySQL 则在互联网业务里占据了大半壁江山尤其是配合读写分离、分库分表这套打法各种坑都已经有很成熟的参考答案。你需要注意的是这两者之间的“迁移成本”比你想象中大。别看都是 SQL字段类型、自增主键、日期函数、索引语法都有差异。我见过不少项目强行从 MySQL 迁 PostgreSQL结果业务没变光改语法就改了几个月中间还出了不少隐性 bug。2.3 我看到的关系型数据库误用场景关系型虽好但真不是万能的。我在项目里见过三类比较典型的误用写出来给大家避坑。第一类是拿关系型硬存 JSON。有些业务字段变来变去团队为了省事把整个动态结构塞进一个 text 或 json 字段结果后期要按内部字段做筛选统计时SQL 写得又丑又慢。如果这种非结构化占比很高不如直接考虑文档型数据库如果只是偶尔有动态属性那就用 PostgreSQL 的 jsonb 加 GIN 索引别用 MySQL 的裸 JSON 去硬刚。第二类是单表数据量大到无法收拾还一直扛着。单表数据到了千万级、亿级索引一深写入开始变慢查询也可能走错执行计划。这时候你就得考虑分区表或者干脆分库分表。关系型本身不差但设计阶段没做容量规划后面全是债。第三类是接口层面完全不需要复杂 SQL就想要低延迟高并发读写也硬上了关系型。比如独立计数器、会话存储、排行榜这些用 Redis 更合适。关系型不是跑不了这个量而是同样的硬件成本用 Redis 能扛十倍的量何必呢。这里给一个关键提示关系型数据库的默认配置不一定适合你的业务。MySQL 的 InnoDB 缓冲池大小、连接数上限、慢查询日志这些装完就要根据自己的机器和业务特征去调。我见过很多团队装上 MySQL 后完全用默认配置跑到几百并发就开始大量慢查询然后抱怨数据库不行其实折腾一下配置就好了。3. 文档型数据库灵活 Schema 的代价与回报3.1 文档模型的优势到底在哪里文档型数据库的代表是 MongoDB还有 Couchbase、Amazon DocumentDB。它和你存的“文档”字面意思不一定有关更准确的理解是“把一整条业务数据存成一个大 JSON 对象”。打个比方关系型要把一个订单拆成订单表、订单明细表、商品表、用户表四张表来存储查询时再 JOIN 回来文档型则是直接把订单连同明细、收货地址、用户快照全部塞进一个文档里。读一次就拿到完整数据不用做昂贵的关联查询。这种模型最大的优势是“贴近业务的自然表达”。业务里的一个订单本来就是一个整体文档型数据库允许你用这个整体直接去建表和查询。另外一个不可忽视的优点是 Schema 灵活今天订单里要加一个优惠券字段关系型要改表加列文档型直接往里写就行了不用做迁移也不用担心老数据没有这个字段导致查询报错。此外文档型数据库在水平扩展方面天然比传统关系型更友好。MongoDB 通过分片把数据按某个键分布到多台机器上应用层不需要太关心路由逻辑这在数据量增长的后期省了很多事。3.2 MongoDB 选型时真正要盯住的几个点如果你决定用 MongoDB有几个细节我得专门拿出来讲因为它们直接影响后期的体验。第一个是 _id 设计。MongoDB 默认给你一个 ObjectId 作为主键但如果你在设计集合时没想好业务主键后面做 upsert、去重、分片都会很难受。我一般建议如果业务里天然有唯一标识比如订单号、用户 ID就把它作为 _id如果需要自增风格的单调 ID那要看场景不建议为了“看起来像 MySQL”去强行搞自增分布式环境下的自增本身就很麻烦。第二个是索引规划。MongoDB 在没有走索引时全表扫描的性能下降非常剧烈。创建索引前先想清楚业务查询模式哪些字段经常作为筛选条件哪些字段用于排序建立一个复合索引时的字段顺序也很有讲究经验法则是“等值条件放前面排序字段放后面”。很多性能问题说白了就是没建对索引。第三个是副本集和分片的边界。副本集解决的是高可用和读扩展但单副本集的写性能和容量是有上限的。真正到了需要分片的规模你的分片键选择就非常关键必须选一个分布足够均匀且符合主要查询模式的字段否则会出现一个分片上的数据远超其他分片也就是所谓的“热分片”。这个键一旦定下来基本很难改所以一定要谨慎。说句实在话MongoDB 在一些人印象里是“不用写 SQL、很随意”的数据库这可能是个误区。它确实让数据结构灵活了不少但索引、查询优化、副本集这些东西一个都不能少。3.3 文档型数据库的边界在哪里文档型数据库的灵活后面藏着一些限制如果你踩到了它的盲区代价会很大。最明显的是多文档事务与复杂关联。MongoDB 从 4.0 开始支持多文档事务但它的事务能力和关系型相比还是有差距而且在高并发下性能开销更明显。如果你的核心领域模型是强关系网络比如复杂的进销存、多级审批、资金清结算数据之间的 JOIN 和联动太频繁硬用文档型就会非常别扭。另一个边界是任意维度的报表汇总。文档模型擅长“按主键取一个整体”但如果你要按十来个维度随意组合做 BI 报表比如按地区、按渠道、按商品类目、按时间段去聚合统计文档型数据库写起来会特别难受。这种场景其实更适合把数据同步到分析型数据库或数据仓库里去做。还有一点常被忽略字段级别的一致性。文档型数据库没有强制的表结构就意味着写入脏数据的概率更高。比如 state 字段你在代码里写成了“success”另一个服务写成了“Success”关系型可以约束枚举值文档型默认不管。所以如果你决定用 MongoDB一定要在应用层做一套严格的校验兜底否则数据质量会悄悄烂掉。4. 键值型数据库高性能背后的设计约束4.1 Redis 为什么能这么快键值型数据库的典型代表是 Redis 和 Memcached。这类数据库的核心场景不是存全量业务数据而是把“需要超级低延迟高频访问”的数据放到内存里用最简单的 Key-Value 模型去读写。Redis 能快主要有三个原因。第一数据在内存里天然比访问磁盘快几个数量级第二它的 IO 模型用单线程加多路复用来处理海量连接省去了线程切换的很多开销第三它不是只会 GET/SET 两个命令而是内置了丰富的数据结构——String、Hash、List、Set、ZSet 等等这意味着排行榜、计数器、去重、消息队列这些逻辑可以直接在服务端完成不用把数据拉回应用层再算一遍。拿 ZSet 举例一个热门排行榜功能传统关系型用 SQL 做 ORDER BY 和 LIMIT数据量大一点就要做缓存和索引优化Redis 只需要一个 ZADD 把分数写进去ZREVRANGE 直接取出 TopN整个过程在几毫秒内完成代码量也少得多。4.2 键值型数据库适合哪几类业务根据我自己的使用经验键值型数据库在下面几类场景几乎是最优解。缓存是最大的一类。热点数据比如商品详情、用户配置、首页聚合数据先查 Redis没有再从数据库加载并回填。这里要注意设计好失效策略和穿透防护不然 Redis 会变成一个永远慢一拍的“复读机”数据库该压垮还是会被压垮。计数器场景也很典型。文章的阅读数、视频的播放量、抽奖活动的参与次数直接用 INCR 命令原子自增完全不担心并发覆盖。收到消息队列里的死信数据想做去重也可以用 SET 配合过期时间实现。会话存储和分布式锁同样是 Redis 的拿手好戏。用户登录态用一个带过期时间的 Key 就能管好多个服务节点要抢同一把锁可以用 SET NX EX 这种原子命令来实现很多分布式锁框架底层就是这么干的。4.3 键值型数据库不是万能缓存虽然 Redis 很好用但我也见过不少项目把 Redis 用成了“埋葬数据的墓场”等出问题才发现悔之晚矣。最大的坑是把 Redis 当主存储。Redis 虽然有持久化机制但本质上还是为缓存设计的它的持久化跟真正的数据库比仍然有风险RDB 快照可能丢最近几秒的数据AOF 追加日志在极端情况下可能恢复不完全。更现实的问题是内存太贵一台高配 MySQL 能存几 TB 数据同样的钱买 Redis 内存可能只有几个 GB。所以关键业务数据必须放到磁盘数据库里Redis 只做加速层。第二个坑是忽略 key 的设计。一个 key 不带业务前缀、不带冒号分层管理起来就是一场灾难。比如统计用户订单数有人用 user:123:count有人用 ordercount123还有人直接用 123abc等到你想按前缀批量扫描或者做数据迁移时就会体会到什么叫毫无头绪。我建议团队一定要把 key 的命名规范写进开发规范里像 user:{uid}:profile 这样的层级结构既清晰又便于后续处理。第三个坑是内存淘汰和数据过期策略没有提前设计。Redis 提供了 noeviction、allkeys-lru、volatile-lru 等不同策略一旦选错或者一直用默认策略内存满了就会开始主动丢 key丢的还是不被注意的数据。等到线上出现查询为空、缓存雪崩时再排查往往业务已经被影响了。还有一个经常被忽略的细节是连接数和慢日志。Redis 单线程模型下如果出现一个耗时极长的慢命令比如大 key 的 KEYS 扫描或超大集合的 SORT整个实例的响应都会被拖慢。所以生产环境里必须禁用 KEYS 命令用 SCAN 代替连接数也要在客户端连接池里控制好。5. 向量数据库AI 时代的第四种选择5.1 为什么传统数据库搞不定向量检索这两年 AI 项目特别多向量数据库像 Milvus、Chroma、Qdrant 也跟着火了。很多人第一次接触向量数据库时会问一个问题把向量存进 PostgreSQL 或者 MySQL然后去查不行吗还真不行或者说很难做好。原因是向量检索的本质是“找最近邻”。一个文本变成了一个几百维的浮点数组你要找“和这个向量最相似的另外几个向量”传统数据库的索引结构比如 BTree对高维空间距离计算完全无能为力。如果你用最暴力的方式全表遍历去逐行算距离数据量到几十万条已经是灾难了更别说上千万上亿条。向量数据库解决这个问题靠的是专门的近似最近邻索引算法比如 HNSW分层可导航小世界图、IVF倒排文件索引、PQ乘积量化。这些算法用“允许稍有误差”换来了数量级的速度提升。比如说 HNSW 的原理可以粗略理解为给所有向量构建了一张多层“朋友网络”先从粗层级快速跳到目标区域再在细层级里精确找邻居检索耗时能压到几十毫秒内。搜索质量、延迟和内存占用三者之间又要做取舍这也是向量数据库选型时最核心的权衡点。5.2 Milvus、Chroma、Qdrant三款主流向量数据库怎么选我尽量结合实战经验把这三款主流的产品做个对比方便你做个初步判断。先说背景Chroma 属于轻量级嵌入式选手Milvus 属于大规模分布式方向Qdrant 则相对均衡Rust 编写既可以嵌入式也可以部署成服务。对比维度MilvusChromaQdrant定位分布式大规模向量检索平台轻量级嵌入式向量库高性能向量搜索引擎部署复杂度较高依赖 etcd、MinIO 等组件极低pip 安装即可较低单个二进制或容器扩展性强支持分布式、海量数据弱适合单机原型和小项目中等支持分布式部署元数据过滤能力强支持复杂过滤条件基础强过滤与向量检索可结合适合场景生产级、大规模、云原生平台快速原型、教学、小规模应用生产可用、性能敏感型应用配套生态有官方 SDK、可视化工具、监控Python 生态友好官方 SDK 全面支持多种语言如果你只是想在本地快速验证 RAG检索增强生成流程Chroma 是最省事的一条 pip install chromadb 就搞定甚至不用独立部署服务直接在 Python 进程里用。但它的扩展性有限数据量大了或者要支持多语言多服务访问时会比较吃力。如果项目一上来就是生产环境数据量在千万级以上而且未来可能要上亿那 Milvus 是比较稳妥的选择。它本身就是为大规模分布式设计的分片、副本、监控、权限都做得比较完整。但代价是部署和运维成本高入门门槛不低小团队没有容器化编排经验的话会有点吃力。Qdrant 则是一个我很喜欢的中间选项它用 Rust 写单机性能很出色部署只需要一个二进制文件或 Docker 容器同时它也自带过滤功能也就是说你可以把“向量检索”和“按标签过滤”两个条件合并到一次查询里。很多 RAG 应用、推荐系统、图片检索场景用它做生产环境很合适。补充一个实操细节这三家都支持 Docker但本地开发时 Qdrant 还提供了嵌入式模式直接在 Python 代码里指定 path 参数就能把数据写到本地目录特别适合在 CI 流水线里做集成测试不用额外起服务。5.3 快速上手一个 Qdrant 向量检索方案我以一个最常用的文本语义检索场景为例演示 Qdrant 的用法。这里用了本地嵌入式模式方便你直接跑通。from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct # 本地嵌入式模式适合开发调试生产环境建议改为服务端模式 client QdrantClient(path./qdrant_demo) # 创建集合向量维度要与embedding模型输出维度一致这里以4维演示 client.create_collection( collection_namedemo_articles, vectors_configVectorParams(size4, distanceDistance.COSINE), ) # 写入向量和payload client.upsert( collection_namedemo_articles, points[ PointStruct( id1, vector[0.1, 0.2, 0.3, 0.4], payload{title: 数据库选型指南, category: database}, ), PointStruct( id2, vector[0.2, 0.1, 0.5, 0.2], payload{title: Redis实战笔记, category: cache}, ), ], ) # 检索和 [0.15, 0.18, 0.32, 0.38] 最相似的 3 条结果 query_vector [0.15, 0.18, 0.32, 0.38] hits client.search( collection_namedemo_articles, query_vectorquery_vector, limit3, append_payloadTrue, ) for hit in hits: print(hit.id, hit.score, hit.payload)实际生产环境里要注意几个点向量维度通常是从嵌入模型输出的比如 OpenAI 的 text-embedding-3-small 是 1536 维本地用 BGE 系列可能是 768 维一定要保持一致。距离函数一般选 COSINE 做文本相似度如果做的是实体匹配或图片特征可以视情况用点积或欧氏距离。写入时要进行 batch 批量提交不要一条一条 upsert性能会差很多。5.4 向量数据库的坑与经验第一批坑集中在索引参数上。HNSW 的两个关键参数是 M每个节点的最大连接数和 ef_construction构建索引时的动态列表大小。M 越大查询越准但内存越高ef_construction 越大索引质量越好但构建越慢。这些参数必须根据你自己的数据去试网上不会有一个“万能值”。第二批坑是关于召回率评估的。向量数据库是近似检索它不是精确检索很多人在上线后才发现某些相似结果没有被召回。所以选型前期就要建立评测集准备一批标准问题人工标注期望召回的文档再把检索结果拿来做对比让召回率指标可见。否则模型库换一个 embedding 模型、换一组参数效果浮动你都察觉不到。第三批坑是向量和元数据过滤的结合顺序。比如我要搜“数据库相关文章并且分类是 database”。如果先按分类过滤再算向量距离分类条件走了索引性能很棒如果不做过滤就直接做向量检索返回结果里可能混进大量无关分类内容。Qdrant 这类支持 payload 过滤的库要把过滤条件和向量查询一起提交而不是检索完再在应用层筛。第四批坑是数据更新问题。业务里文档总是要更新、删除向量库里对应向量也要跟着同步。这里就涉及“链路设计”了业务数据更新时是同步调用 embedding 模型生成新向量再写入向量库还是异步通过消息队列做同步方案一致性更好但延迟高异步方案吞吐高但要处理失败重试。个人经验是异步方案配合定期全量校准是大多数系统的现实选择。注意向量数据库不是替代品它是补充品。永远把核心生产数据放在可信的数据库里向量库可以存放派生出来的向量副本这样即使向量库挂了你还能从源系统重建。6. 混合架构选型不是单选是多选组合6.1 多数据库共存的常见组合模式选型做多了你会发现真正健壮的系统很少只用一种数据库更多是“多个数据库各管一段”的组合架构。我整理一种非常常见的组合MySQL 管账务、订单、用户主数据等强一致核心数据Redis 管缓存、计数器、会话、排行榜Elasticsearch 管全文搜索和日志检索MongoDB 管内容、配置、草稿这类结构灵活的数据如果做了 RAG 或语义推荐再接一个 Qdrant 或 Milvus 管向量检索。这个组合看起来复杂实际上每一层职责单一容量规划和故障隔离都清晰得多。数据流也相对自然应用层先写 MySQL 和 MongoDB 这种“源数据”存储再通过异步任务把衍生数据同步到 Redis、Elasticsearch、向量库里。商品信息变了同步去更新搜索索引和向量库而不是让各系统各查各的源表。这样一旦某个辅助存储挂了核心业务不受影响辅助功能降级就好。6.2 如何降低多数据库的运维成本很多人一听混合架构就头疼觉得运维负担太重。但没有必要被吓退设计得当的话多数据库组合不会比单数据库复杂太多。第一能托管就托管。云厂商的托管数据库自带备份、监控、高可用比自己买机器搭主从要省心得多。同样一个 Redis自建要处理持久化策略、主从切换、监控告警托管版直接填一个规格就能用。第二数据同步一定要靠工具而不是人工脚本。比如 MySQL 到 Elasticsearch 或 MongoDB 的同步用 CDC变更数据捕获工具订阅 binlog 自动同步经历了多年检验比每天写定时任务去拉全量要可靠。向量库的数据同步可以走应用侧双写但要做好失败补偿给每批同步任务加状态记录和重试机制。第三做好归档和降级预案。线上数据不要无限堆在同一个库中历史数据按时间定期归档到冷存储。辅助存储故障时应用要能被降级开关控制比如 Redis 挂了就直接查 MySQL推荐流挂了就隐藏推荐模块而不是让整个接口报 500。提示在引入任何新数据库之前先想清楚“这个库如果挂了我怎么降级”如果答不上来说明你还不到引入它的时候。7. 常见问题与排查技巧实录7.1 选型阶段大家最爱问的几个问题我经常被问到一类问题“MySQL 和 MongoDB 选哪个好”这种问法其实有点像是问“汽车和自行车哪个好”得先说清楚你是要在高速公路上跑长途还是在家门口买菜。我把几个高频问题整理成了速查思路建议你在心里先回答需求全景再对齐下面的答案。“Redis 能当主数据库用吗”答案是不建议。它更适合做加速层关键数据仍然要有磁盘数据库兜底。如果你真的只有几个 GB 数据、高并发读是唯一痛点、丢失几秒数据也能接受那技术上可以硬上但绝大多数团队不适合。“有 PostgreSQL 还需要 Elasticsearch 吗”看具体功能。如果业务只是简单文本匹配PostgreSQL 全文检索可以顶一阵但如果要做分词、拼音纠错、复杂打分、字段聚合ES 的成熟度优势还是很明显。“上了向量数据库是不是就不用做关键词搜索了”不是。语义检索和关键词检索解决的是不同类型的问题前者处理“意思相近但措辞不同”后者处理“限量精确匹配更可控”。很多系统正是同时保留两套检索再做结果融合。7.2 从一种数据库迁到另一种数据库的实操经验最后分享一点迁移经验因为选型经常不是从零开始而是要把现有系统从一种数据库搬到另一种。迁移最容易踩的坑是“用新库模拟旧库的 SQL”比如从 MySQL 迁到 MongoDB却非要把关系模型原封不动搬过去结果失去了灵活优势还引入了大量跨文档查询。我的建议是借迁移的机会重构数据模型。真正困难的不是搬数据而是把业务读写路径同步切换。线上迁移要设计好灰度方案不能“一次性切换”比较好的做法是长时间双写同时从新库读取验证一致性跑一段时间对比数据对账无误后再把读流量逐步切过去。这个周期看起来长但回滚成本极低对线上影响可控。迁移中最大的隐性开销是团队学习和心理成本。引入一个新数据库团队成员需要重新适应它的查询语法、索引机制、调优手段这往往需要几个月的过渡期。所以我在选型时一直会强调选出来的数据库不仅要是对业务最合适的也要是团队在可接受时间内能真正驾驭的。纸面上再优秀的方案如果团队用不起来落地时都会变成灾难。我自己现在做选型时的习惯很简单涉及钱、订单、权限这类强一致业务关系型打底结构变化快的活动配置、内容草稿文档型兜底热点数据、登录态、排行榜用 Redis 先顶着要做语义检索、相似推荐再单独接一个向量库而不是让业务去迁就一个花里胡哨的数据库。数据库选型没有标准答案但你按照这套思路一步步拆下来至少不会选得离谱。 数据库选型不再难：关系型、文档型、键值型、向量数据库全解析
做了十几年数据相关的工作我见过太多次数据库选型现场变成辩论赛。后端说 MySQL 稳算法说得上向量库领导说 Redis 快DBA 说你们都在给我挖坑。最后谁赢往往不是最符合业务的而是嗓门最大的。我自己也经历过这种混乱期直到把这套选型的逻辑彻底捋顺才发现数据库选型这事情其实有迹可循它根本不是从数据库目录里挑一个顺眼的名字而是先把业务翻译成一系列数据需求再让数据库去匹配这些需求。关系型、文档型、键值型、向量型今天市面上叫得上名字的数据库少说也有几十种各有各的擅长也各有各的短板。这篇指南不打算给你排一个什么“十大数据库排行榜”而是把我这些年做架构选型时真正用到的思考框架、对比维度和落地经验全部摊开来讲尽量让新手也能顺着这套思路去做判断。我会从最基础的决策逻辑讲起再分别拆解关系型、文档型、键值型和这两年特别火的向量数据库最后聊一聊它们怎么组合使用。如果你正准备给新项目做技术选型或者想把现有系统里的某个存储换掉这篇文章应该能帮你省掉不少踩坑的时间。1. 选型真正的起点先别谈技术谈业务1.1 一个真实需求引发的思考我拿自己带过的一个实际项目举例。那是一个内容社区类产品用户要注册登录能发文章、写评论、点赞收藏后续还打算上一个“猜你喜欢”的推荐流。当时团队内部就炸了锅有人说用 MySQL有人说用 MongoDB还有人建议加 Redis搞推荐的同学说要上向量数据库。每个提议单独看都有道理但放在一起就变成了一团乱麻。问题出在哪大家把“选哪个数据库”当成了一个单选题但真实的业务需求从来不是一个维度。注册登录和文章发布涉及状态变更需要强一致性文章和评论这种内容天然是嵌套结构字段还可能随时增加点赞数、阅读量这种热数据要求极低的读写延迟推荐流又需要把文本或图片变成向量去算相似度。你把这几个诉求摆到桌面上答案其实是清楚的根本不是一个数据库能解决全部问题而是需要一组数据库各管一段。所以我后来在做选型时第一步永远不是打开数据库对比文档而是拿着业务需求一条条问下去直到把所有涉及数据存储和访问的诉求收集完整。1.2 四步需求拆解法我把这套收集和拆解的方法归纳成四步每次选型前对着走一遍基本能筛掉 80% 的错误选项。第一步看数据形态。你的数据是规规矩矩的表格状结构字段固定、关联明确还是嵌套很深的文档结构字段说变就变又或者只是一些临时性的键值对比如用户会话、验证码如果是高维向量比如几百维的文本 embedding那传统数据库压根不是你想不想用的问题而是根本查不动。这一步能把候选范围先圈出来。第二步看访问模式。业务是读多写少还是写多读少查询是固定几个模板比如按 ID 查、按用户查还是用户能随意组合任意字段做筛选固定模板适合 KV 数据库任意组合筛查就需要支持灵活查询的引擎。还要看你对查询延迟的容忍度100 毫秒可以接受还是必须压到 1 毫秒以下第三步看一致性和事务要求。账务、订单、库存这类场景数据错一笔都是事故必须支持严格的事务和强一致但像文章的点赞数、用户的浏览记录少一条或多一条几乎没有感知完全可以用弱一致换性能。很多选型翻车就是因为团队把不需要事务的场景硬塞进了支持事务的数据库把性能拖垮了反过来也有团队为了性能牺牲了事务最后对不上账。第四步看规模和演进。现在数据量是百万级但产品做起来之后三年可能到亿级这个量级对分库分表、水平扩展的要求完全不同。同时一定要评估团队的运维能力把 MySQL 玩明白已经需要一定功力了直接上一个分布式的 NewSQL团队没人啃得动最后可能连备份恢复都成问题。这四步跑完你会发现每种候选数据库适合什么、不适合什么已经清楚了一大半。后面几章我再逐个数据库类型来拆。2. 关系型数据库什么时候选它什么时候别硬选2.1 关系型数据库到底解决了什么问题关系型数据库是过去几十年最主流的存储方案MySQL、PostgreSQL、Oracle、SQL Server 都属于这一类。它的核心价值用一个词概括就是“确定性”。数据要遵守预先定义好的表结构每一列有明确类型表与表之间靠外键维护关系写入时通过事务保证要么全部成功要么全部失败。这套设计极其适合账务、订单、用户主数据这类业务因为数据的一致性容不得半点模糊。很多人会用“Excel 表格”来类比关系型数据库但更准确的类比是“带严格规章制度的 Excel”你只能在固定的列里填固定类型的内容当你要同时改两张表时数据库会确保要么两张表都改成功要么一张都不动。这种能力在金融、电商、ERP、CRM 这类场景里是刚需。关系型的第二个优势是 SQL。不要小看 SQL 这门语言的标准性它能让你用同一套语法完成建表、增删改查、多表关联、聚合统计而且无论是 MySQL 还是 PostgreSQL迁移到彼此的语法差异远小于换一个数据模型。团队成员普遍会写 SQL招聘成本也低。还有一个容易被低估的点是生态成熟度。关系型数据库的监控工具、备份方案、数据迁移工具、云服务托管版本都非常成熟。你踩过的坑网上基本都能搜到答案。这和用一些刚兴起的数据库是完全不一样的体验。2.2 MySQL还是PostgreSQL五个关键差异落到具体选型团队问得最多的就是 MySQL 和 PostgreSQL 怎么二选一。我直接给结论绝大多数场景这俩都能干但侧重点不同。我整理了一个对比表对比维度MySQLPostgreSQL默认事务隔离级别可重复读RR读已提交RCJSON 支持有 JSON 类型但查询能力有限jsonb 支持 GIN 索引查询能力很强全文检索一般需要额外插件内置 tsvector开箱即用复杂查询与窗口函数支持但部分语法较弱支持非常全面CTE 和窗口函数强大扩展性方向读写分离、分库分表方案多运维资料极其丰富既有分布式方案也有丰富外部数据源扩展FDW按我的实际使用经验PostgreSQL 更适合数据模型复杂、查询逻辑绕、需要处理半结构化大 JSON 的业务MySQL 则在互联网业务里占据了大半壁江山尤其是配合读写分离、分库分表这套打法各种坑都已经有很成熟的参考答案。你需要注意的是这两者之间的“迁移成本”比你想象中大。别看都是 SQL字段类型、自增主键、日期函数、索引语法都有差异。我见过不少项目强行从 MySQL 迁 PostgreSQL结果业务没变光改语法就改了几个月中间还出了不少隐性 bug。2.3 我看到的关系型数据库误用场景关系型虽好但真不是万能的。我在项目里见过三类比较典型的误用写出来给大家避坑。第一类是拿关系型硬存 JSON。有些业务字段变来变去团队为了省事把整个动态结构塞进一个 text 或 json 字段结果后期要按内部字段做筛选统计时SQL 写得又丑又慢。如果这种非结构化占比很高不如直接考虑文档型数据库如果只是偶尔有动态属性那就用 PostgreSQL 的 jsonb 加 GIN 索引别用 MySQL 的裸 JSON 去硬刚。第二类是单表数据量大到无法收拾还一直扛着。单表数据到了千万级、亿级索引一深写入开始变慢查询也可能走错执行计划。这时候你就得考虑分区表或者干脆分库分表。关系型本身不差但设计阶段没做容量规划后面全是债。第三类是接口层面完全不需要复杂 SQL就想要低延迟高并发读写也硬上了关系型。比如独立计数器、会话存储、排行榜这些用 Redis 更合适。关系型不是跑不了这个量而是同样的硬件成本用 Redis 能扛十倍的量何必呢。这里给一个关键提示关系型数据库的默认配置不一定适合你的业务。MySQL 的 InnoDB 缓冲池大小、连接数上限、慢查询日志这些装完就要根据自己的机器和业务特征去调。我见过很多团队装上 MySQL 后完全用默认配置跑到几百并发就开始大量慢查询然后抱怨数据库不行其实折腾一下配置就好了。3. 文档型数据库灵活 Schema 的代价与回报3.1 文档模型的优势到底在哪里文档型数据库的代表是 MongoDB还有 Couchbase、Amazon DocumentDB。它和你存的“文档”字面意思不一定有关更准确的理解是“把一整条业务数据存成一个大 JSON 对象”。打个比方关系型要把一个订单拆成订单表、订单明细表、商品表、用户表四张表来存储查询时再 JOIN 回来文档型则是直接把订单连同明细、收货地址、用户快照全部塞进一个文档里。读一次就拿到完整数据不用做昂贵的关联查询。这种模型最大的优势是“贴近业务的自然表达”。业务里的一个订单本来就是一个整体文档型数据库允许你用这个整体直接去建表和查询。另外一个不可忽视的优点是 Schema 灵活今天订单里要加一个优惠券字段关系型要改表加列文档型直接往里写就行了不用做迁移也不用担心老数据没有这个字段导致查询报错。此外文档型数据库在水平扩展方面天然比传统关系型更友好。MongoDB 通过分片把数据按某个键分布到多台机器上应用层不需要太关心路由逻辑这在数据量增长的后期省了很多事。3.2 MongoDB 选型时真正要盯住的几个点如果你决定用 MongoDB有几个细节我得专门拿出来讲因为它们直接影响后期的体验。第一个是 _id 设计。MongoDB 默认给你一个 ObjectId 作为主键但如果你在设计集合时没想好业务主键后面做 upsert、去重、分片都会很难受。我一般建议如果业务里天然有唯一标识比如订单号、用户 ID就把它作为 _id如果需要自增风格的单调 ID那要看场景不建议为了“看起来像 MySQL”去强行搞自增分布式环境下的自增本身就很麻烦。第二个是索引规划。MongoDB 在没有走索引时全表扫描的性能下降非常剧烈。创建索引前先想清楚业务查询模式哪些字段经常作为筛选条件哪些字段用于排序建立一个复合索引时的字段顺序也很有讲究经验法则是“等值条件放前面排序字段放后面”。很多性能问题说白了就是没建对索引。第三个是副本集和分片的边界。副本集解决的是高可用和读扩展但单副本集的写性能和容量是有上限的。真正到了需要分片的规模你的分片键选择就非常关键必须选一个分布足够均匀且符合主要查询模式的字段否则会出现一个分片上的数据远超其他分片也就是所谓的“热分片”。这个键一旦定下来基本很难改所以一定要谨慎。说句实在话MongoDB 在一些人印象里是“不用写 SQL、很随意”的数据库这可能是个误区。它确实让数据结构灵活了不少但索引、查询优化、副本集这些东西一个都不能少。3.3 文档型数据库的边界在哪里文档型数据库的灵活后面藏着一些限制如果你踩到了它的盲区代价会很大。最明显的是多文档事务与复杂关联。MongoDB 从 4.0 开始支持多文档事务但它的事务能力和关系型相比还是有差距而且在高并发下性能开销更明显。如果你的核心领域模型是强关系网络比如复杂的进销存、多级审批、资金清结算数据之间的 JOIN 和联动太频繁硬用文档型就会非常别扭。另一个边界是任意维度的报表汇总。文档模型擅长“按主键取一个整体”但如果你要按十来个维度随意组合做 BI 报表比如按地区、按渠道、按商品类目、按时间段去聚合统计文档型数据库写起来会特别难受。这种场景其实更适合把数据同步到分析型数据库或数据仓库里去做。还有一点常被忽略字段级别的一致性。文档型数据库没有强制的表结构就意味着写入脏数据的概率更高。比如 state 字段你在代码里写成了“success”另一个服务写成了“Success”关系型可以约束枚举值文档型默认不管。所以如果你决定用 MongoDB一定要在应用层做一套严格的校验兜底否则数据质量会悄悄烂掉。4. 键值型数据库高性能背后的设计约束4.1 Redis 为什么能这么快键值型数据库的典型代表是 Redis 和 Memcached。这类数据库的核心场景不是存全量业务数据而是把“需要超级低延迟高频访问”的数据放到内存里用最简单的 Key-Value 模型去读写。Redis 能快主要有三个原因。第一数据在内存里天然比访问磁盘快几个数量级第二它的 IO 模型用单线程加多路复用来处理海量连接省去了线程切换的很多开销第三它不是只会 GET/SET 两个命令而是内置了丰富的数据结构——String、Hash、List、Set、ZSet 等等这意味着排行榜、计数器、去重、消息队列这些逻辑可以直接在服务端完成不用把数据拉回应用层再算一遍。拿 ZSet 举例一个热门排行榜功能传统关系型用 SQL 做 ORDER BY 和 LIMIT数据量大一点就要做缓存和索引优化Redis 只需要一个 ZADD 把分数写进去ZREVRANGE 直接取出 TopN整个过程在几毫秒内完成代码量也少得多。4.2 键值型数据库适合哪几类业务根据我自己的使用经验键值型数据库在下面几类场景几乎是最优解。缓存是最大的一类。热点数据比如商品详情、用户配置、首页聚合数据先查 Redis没有再从数据库加载并回填。这里要注意设计好失效策略和穿透防护不然 Redis 会变成一个永远慢一拍的“复读机”数据库该压垮还是会被压垮。计数器场景也很典型。文章的阅读数、视频的播放量、抽奖活动的参与次数直接用 INCR 命令原子自增完全不担心并发覆盖。收到消息队列里的死信数据想做去重也可以用 SET 配合过期时间实现。会话存储和分布式锁同样是 Redis 的拿手好戏。用户登录态用一个带过期时间的 Key 就能管好多个服务节点要抢同一把锁可以用 SET NX EX 这种原子命令来实现很多分布式锁框架底层就是这么干的。4.3 键值型数据库不是万能缓存虽然 Redis 很好用但我也见过不少项目把 Redis 用成了“埋葬数据的墓场”等出问题才发现悔之晚矣。最大的坑是把 Redis 当主存储。Redis 虽然有持久化机制但本质上还是为缓存设计的它的持久化跟真正的数据库比仍然有风险RDB 快照可能丢最近几秒的数据AOF 追加日志在极端情况下可能恢复不完全。更现实的问题是内存太贵一台高配 MySQL 能存几 TB 数据同样的钱买 Redis 内存可能只有几个 GB。所以关键业务数据必须放到磁盘数据库里Redis 只做加速层。第二个坑是忽略 key 的设计。一个 key 不带业务前缀、不带冒号分层管理起来就是一场灾难。比如统计用户订单数有人用 user:123:count有人用 ordercount123还有人直接用 123abc等到你想按前缀批量扫描或者做数据迁移时就会体会到什么叫毫无头绪。我建议团队一定要把 key 的命名规范写进开发规范里像 user:{uid}:profile 这样的层级结构既清晰又便于后续处理。第三个坑是内存淘汰和数据过期策略没有提前设计。Redis 提供了 noeviction、allkeys-lru、volatile-lru 等不同策略一旦选错或者一直用默认策略内存满了就会开始主动丢 key丢的还是不被注意的数据。等到线上出现查询为空、缓存雪崩时再排查往往业务已经被影响了。还有一个经常被忽略的细节是连接数和慢日志。Redis 单线程模型下如果出现一个耗时极长的慢命令比如大 key 的 KEYS 扫描或超大集合的 SORT整个实例的响应都会被拖慢。所以生产环境里必须禁用 KEYS 命令用 SCAN 代替连接数也要在客户端连接池里控制好。5. 向量数据库AI 时代的第四种选择5.1 为什么传统数据库搞不定向量检索这两年 AI 项目特别多向量数据库像 Milvus、Chroma、Qdrant 也跟着火了。很多人第一次接触向量数据库时会问一个问题把向量存进 PostgreSQL 或者 MySQL然后去查不行吗还真不行或者说很难做好。原因是向量检索的本质是“找最近邻”。一个文本变成了一个几百维的浮点数组你要找“和这个向量最相似的另外几个向量”传统数据库的索引结构比如 BTree对高维空间距离计算完全无能为力。如果你用最暴力的方式全表遍历去逐行算距离数据量到几十万条已经是灾难了更别说上千万上亿条。向量数据库解决这个问题靠的是专门的近似最近邻索引算法比如 HNSW分层可导航小世界图、IVF倒排文件索引、PQ乘积量化。这些算法用“允许稍有误差”换来了数量级的速度提升。比如说 HNSW 的原理可以粗略理解为给所有向量构建了一张多层“朋友网络”先从粗层级快速跳到目标区域再在细层级里精确找邻居检索耗时能压到几十毫秒内。搜索质量、延迟和内存占用三者之间又要做取舍这也是向量数据库选型时最核心的权衡点。5.2 Milvus、Chroma、Qdrant三款主流向量数据库怎么选我尽量结合实战经验把这三款主流的产品做个对比方便你做个初步判断。先说背景Chroma 属于轻量级嵌入式选手Milvus 属于大规模分布式方向Qdrant 则相对均衡Rust 编写既可以嵌入式也可以部署成服务。对比维度MilvusChromaQdrant定位分布式大规模向量检索平台轻量级嵌入式向量库高性能向量搜索引擎部署复杂度较高依赖 etcd、MinIO 等组件极低pip 安装即可较低单个二进制或容器扩展性强支持分布式、海量数据弱适合单机原型和小项目中等支持分布式部署元数据过滤能力强支持复杂过滤条件基础强过滤与向量检索可结合适合场景生产级、大规模、云原生平台快速原型、教学、小规模应用生产可用、性能敏感型应用配套生态有官方 SDK、可视化工具、监控Python 生态友好官方 SDK 全面支持多种语言如果你只是想在本地快速验证 RAG检索增强生成流程Chroma 是最省事的一条 pip install chromadb 就搞定甚至不用独立部署服务直接在 Python 进程里用。但它的扩展性有限数据量大了或者要支持多语言多服务访问时会比较吃力。如果项目一上来就是生产环境数据量在千万级以上而且未来可能要上亿那 Milvus 是比较稳妥的选择。它本身就是为大规模分布式设计的分片、副本、监控、权限都做得比较完整。但代价是部署和运维成本高入门门槛不低小团队没有容器化编排经验的话会有点吃力。Qdrant 则是一个我很喜欢的中间选项它用 Rust 写单机性能很出色部署只需要一个二进制文件或 Docker 容器同时它也自带过滤功能也就是说你可以把“向量检索”和“按标签过滤”两个条件合并到一次查询里。很多 RAG 应用、推荐系统、图片检索场景用它做生产环境很合适。补充一个实操细节这三家都支持 Docker但本地开发时 Qdrant 还提供了嵌入式模式直接在 Python 代码里指定 path 参数就能把数据写到本地目录特别适合在 CI 流水线里做集成测试不用额外起服务。5.3 快速上手一个 Qdrant 向量检索方案我以一个最常用的文本语义检索场景为例演示 Qdrant 的用法。这里用了本地嵌入式模式方便你直接跑通。from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct # 本地嵌入式模式适合开发调试生产环境建议改为服务端模式 client QdrantClient(path./qdrant_demo) # 创建集合向量维度要与embedding模型输出维度一致这里以4维演示 client.create_collection( collection_namedemo_articles, vectors_configVectorParams(size4, distanceDistance.COSINE), ) # 写入向量和payload client.upsert( collection_namedemo_articles, points[ PointStruct( id1, vector[0.1, 0.2, 0.3, 0.4], payload{title: 数据库选型指南, category: database}, ), PointStruct( id2, vector[0.2, 0.1, 0.5, 0.2], payload{title: Redis实战笔记, category: cache}, ), ], ) # 检索和 [0.15, 0.18, 0.32, 0.38] 最相似的 3 条结果 query_vector [0.15, 0.18, 0.32, 0.38] hits client.search( collection_namedemo_articles, query_vectorquery_vector, limit3, append_payloadTrue, ) for hit in hits: print(hit.id, hit.score, hit.payload)实际生产环境里要注意几个点向量维度通常是从嵌入模型输出的比如 OpenAI 的 text-embedding-3-small 是 1536 维本地用 BGE 系列可能是 768 维一定要保持一致。距离函数一般选 COSINE 做文本相似度如果做的是实体匹配或图片特征可以视情况用点积或欧氏距离。写入时要进行 batch 批量提交不要一条一条 upsert性能会差很多。5.4 向量数据库的坑与经验第一批坑集中在索引参数上。HNSW 的两个关键参数是 M每个节点的最大连接数和 ef_construction构建索引时的动态列表大小。M 越大查询越准但内存越高ef_construction 越大索引质量越好但构建越慢。这些参数必须根据你自己的数据去试网上不会有一个“万能值”。第二批坑是关于召回率评估的。向量数据库是近似检索它不是精确检索很多人在上线后才发现某些相似结果没有被召回。所以选型前期就要建立评测集准备一批标准问题人工标注期望召回的文档再把检索结果拿来做对比让召回率指标可见。否则模型库换一个 embedding 模型、换一组参数效果浮动你都察觉不到。第三批坑是向量和元数据过滤的结合顺序。比如我要搜“数据库相关文章并且分类是 database”。如果先按分类过滤再算向量距离分类条件走了索引性能很棒如果不做过滤就直接做向量检索返回结果里可能混进大量无关分类内容。Qdrant 这类支持 payload 过滤的库要把过滤条件和向量查询一起提交而不是检索完再在应用层筛。第四批坑是数据更新问题。业务里文档总是要更新、删除向量库里对应向量也要跟着同步。这里就涉及“链路设计”了业务数据更新时是同步调用 embedding 模型生成新向量再写入向量库还是异步通过消息队列做同步方案一致性更好但延迟高异步方案吞吐高但要处理失败重试。个人经验是异步方案配合定期全量校准是大多数系统的现实选择。注意向量数据库不是替代品它是补充品。永远把核心生产数据放在可信的数据库里向量库可以存放派生出来的向量副本这样即使向量库挂了你还能从源系统重建。6. 混合架构选型不是单选是多选组合6.1 多数据库共存的常见组合模式选型做多了你会发现真正健壮的系统很少只用一种数据库更多是“多个数据库各管一段”的组合架构。我整理一种非常常见的组合MySQL 管账务、订单、用户主数据等强一致核心数据Redis 管缓存、计数器、会话、排行榜Elasticsearch 管全文搜索和日志检索MongoDB 管内容、配置、草稿这类结构灵活的数据如果做了 RAG 或语义推荐再接一个 Qdrant 或 Milvus 管向量检索。这个组合看起来复杂实际上每一层职责单一容量规划和故障隔离都清晰得多。数据流也相对自然应用层先写 MySQL 和 MongoDB 这种“源数据”存储再通过异步任务把衍生数据同步到 Redis、Elasticsearch、向量库里。商品信息变了同步去更新搜索索引和向量库而不是让各系统各查各的源表。这样一旦某个辅助存储挂了核心业务不受影响辅助功能降级就好。6.2 如何降低多数据库的运维成本很多人一听混合架构就头疼觉得运维负担太重。但没有必要被吓退设计得当的话多数据库组合不会比单数据库复杂太多。第一能托管就托管。云厂商的托管数据库自带备份、监控、高可用比自己买机器搭主从要省心得多。同样一个 Redis自建要处理持久化策略、主从切换、监控告警托管版直接填一个规格就能用。第二数据同步一定要靠工具而不是人工脚本。比如 MySQL 到 Elasticsearch 或 MongoDB 的同步用 CDC变更数据捕获工具订阅 binlog 自动同步经历了多年检验比每天写定时任务去拉全量要可靠。向量库的数据同步可以走应用侧双写但要做好失败补偿给每批同步任务加状态记录和重试机制。第三做好归档和降级预案。线上数据不要无限堆在同一个库中历史数据按时间定期归档到冷存储。辅助存储故障时应用要能被降级开关控制比如 Redis 挂了就直接查 MySQL推荐流挂了就隐藏推荐模块而不是让整个接口报 500。提示在引入任何新数据库之前先想清楚“这个库如果挂了我怎么降级”如果答不上来说明你还不到引入它的时候。7. 常见问题与排查技巧实录7.1 选型阶段大家最爱问的几个问题我经常被问到一类问题“MySQL 和 MongoDB 选哪个好”这种问法其实有点像是问“汽车和自行车哪个好”得先说清楚你是要在高速公路上跑长途还是在家门口买菜。我把几个高频问题整理成了速查思路建议你在心里先回答需求全景再对齐下面的答案。“Redis 能当主数据库用吗”答案是不建议。它更适合做加速层关键数据仍然要有磁盘数据库兜底。如果你真的只有几个 GB 数据、高并发读是唯一痛点、丢失几秒数据也能接受那技术上可以硬上但绝大多数团队不适合。“有 PostgreSQL 还需要 Elasticsearch 吗”看具体功能。如果业务只是简单文本匹配PostgreSQL 全文检索可以顶一阵但如果要做分词、拼音纠错、复杂打分、字段聚合ES 的成熟度优势还是很明显。“上了向量数据库是不是就不用做关键词搜索了”不是。语义检索和关键词检索解决的是不同类型的问题前者处理“意思相近但措辞不同”后者处理“限量精确匹配更可控”。很多系统正是同时保留两套检索再做结果融合。7.2 从一种数据库迁到另一种数据库的实操经验最后分享一点迁移经验因为选型经常不是从零开始而是要把现有系统从一种数据库搬到另一种。迁移最容易踩的坑是“用新库模拟旧库的 SQL”比如从 MySQL 迁到 MongoDB却非要把关系模型原封不动搬过去结果失去了灵活优势还引入了大量跨文档查询。我的建议是借迁移的机会重构数据模型。真正困难的不是搬数据而是把业务读写路径同步切换。线上迁移要设计好灰度方案不能“一次性切换”比较好的做法是长时间双写同时从新库读取验证一致性跑一段时间对比数据对账无误后再把读流量逐步切过去。这个周期看起来长但回滚成本极低对线上影响可控。迁移中最大的隐性开销是团队学习和心理成本。引入一个新数据库团队成员需要重新适应它的查询语法、索引机制、调优手段这往往需要几个月的过渡期。所以我在选型时一直会强调选出来的数据库不仅要是对业务最合适的也要是团队在可接受时间内能真正驾驭的。纸面上再优秀的方案如果团队用不起来落地时都会变成灾难。我自己现在做选型时的习惯很简单涉及钱、订单、权限这类强一致业务关系型打底结构变化快的活动配置、内容草稿文档型兜底热点数据、登录态、排行榜用 Redis 先顶着要做语义检索、相似推荐再单独接一个向量库而不是让业务去迁就一个花里胡哨的数据库。数据库选型没有标准答案但你按照这套思路一步步拆下来至少不会选得离谱。