主流数据库到底怎么选？一文讲透性能、瓶颈与适用场景
“数据库选哪个”大概是后端面试被问最多次、也最没有标准答案的问题。因为根本不存在’最好的数据库’，只有’最合适当前业务场景的那一个’。这篇把全球最主流的几款数据库逐个讲透——性能表现、功能强项、核心瓶颈——最后给你一张选型表，让你能自己判断。
关系型：PostgreSQL 和 MySQL
PostgreSQL —— 功能最全的全能选手 定位是”最像编程语言的关系库”。功能碾压级的全面：ACID 事务、JSONB（原生存半结构化数据）、全文检索、PostGIS 地理分析、数组/枚举/范围类型、物化视图，还能装 pgvector 搞向量检索。
- 性能：单机读写稳定，复杂查询优化器强，适合业务逻辑复杂、表关系多的系统
- 瓶颈：单机写入并发再高也是有上限的，要做读写分离和 Sharding（相对繁琐）；默认配置偏保守，不调优跑不满硬件
- 一句话：能文能武，中小型系统的”万能答案”
MySQL —— Web 世界的老牌王者 20 多年一直是最流行的 Web 数据库，开发者和运维人才最多，踩坑资料最多。InnoDB 事务、主从复制成熟。
- 性能：简单查询极快，团队调优经验足
- 瓶颈：复杂 SQL 和大数据量分析吃力；JSON 等扩展能力弱于 Postgres；分区、半结构化支持有限
- 一句话：求稳、求熟悉、团队都是 MySQL 老手，选它不算错
NoSQL 与分布式
MongoDB —— 文档模型的灵活派 用文档（JSON 类结构）存数据，schema 可以随便加字段，不用预先设计表结构。内置分片和副本集，横向扩展天然（这是它和关系库最大的区别）。
- 性能：海量数据、高写入场景表现好，字段需经常变的业务最省心
- 瓶颈：多文档事务成本高、JOIN 能力弱（$lookup 有限）、内存占用大（热数据要进内存）、强一致性场景要小心
- 一句话：数据模型变化快、要横向扩展、不想被表结构绑死，选它
Redis —— 内存里的极速缓存 本质是内存 KV 存储，读写微秒级，清单里最快的存在。数据结构丰富：字符串、哈希、列表、集合、有序集合，支持分布式锁、发布订阅、Lua 脚本。
- 性能：毫无疑问的王者，扛亿级 QPS 的缓存层几乎都靠它
- 瓶颈：内存就是成本，数据放不下内存就歇菜；持久化（RDB/AOF）有阻塞风险；单线程模型下长命令要注意（新版本已做多线程 IO）
- 一句话：它是”缓存层”不是”存储层”，别把重要数据全赌在它身上
Elasticsearch —— 全文搜索与分析 基于 Lucene 的倒排索引，专为”搜得快”而生。全文搜索、模糊匹配、多字段聚合分析是它的看家本领。
- 性能：大规模全文检索和聚合，几亿文档也能秒出
- 瓶颈：不适合当主数据库——它是近实时（写入后有一小段延迟才可见）、不保证强一致；堆内存和 GC 配置敏感，磁盘占用大（副本+段合并）；运维复杂
- 一句话：搜索、日志分析、推荐这种场景它无敌，但别把它当”能存就行”的库
ClickHouse —— 列式查询的 OLAP 核弹 列式存储 + 向量化执行，专门为”对海量数据做聚合分析”而生。几十亿行按天做报表、漏斗分析，秒级出结果。
- 性能：OLAP 场景下性能甩传统行存数据库几条街
- 瓶颈：频繁单行插入/更新是它的死穴（适合批量写入，更新去重成本高）；不适合高并发的点查（每条查询开销高）；能力集中在读和聚合
- 一句话：要做数据仓库、BI 报表、行为分析，上它；要做在线业务存储，别用它
Cassandra —— 海量写入的分布式宽列 去中心化架构（P2P），节点平级、线性扩展、没有单点。面向”海量写入 + 高可用 + 全球多地”的场景（典型如日志采集、消息流）。
- 性能：极大规模写入吞吐惊人，扩展靠加节点
- 瓶颈：复杂查询受限——查询基本要按主键走，没那么多灵活姿势；强一致性实现成本高；运维复杂度不低
- 一句话：当你的数据量大到 MySQL 完全扛不住、又要全球分布时，才轮到它
新兴力量：向量数据库
AI 时代冒出来的新类别，专门做语义检索（把文本/图片/知识转成向量，按相似度找）。业界最佳实践是给 PostgreSQL 装 pgvector 扩展（中小规模够用），或者数据量特别大时上专门的 Milvus / Qdrant。
- 一句话：做 RAG、语义搜索、推荐这类 AI 应用，给现有数据库加个向量能力就够了，别动不动就引一个重型向量库
一张表看懂怎么选
| 数据库 | 数据模型 | 性能强项 | 核心瓶颈 | 最佳场景 |
|---|---|---|---|---|
| PostgreSQL | 关系 + 多种扩展 | 复杂查询/功能全面 | 海量写入水平扩展难 | 业务逻辑复杂的核心系统 |
| MySQL | 关系 | 简单查询、生态熟 | 复杂分析与半结构化弱 | Web 应用、传统业务 |
| MongoDB | 文档 | 海量写入、灵活扩展 | 事务/JOIN 弱 | 数据模型多变、需横向扩展 |
| Redis | 内存 KV | 读写最快 | 内存成本、容量受限 | 缓存、会话、限流 |
| Elasticsearch | 倒排索引 | 全文搜索/聚合 | 非主存、运维重 | 搜索、日志分析 |
| ClickHouse | 列式 | 海量聚合分析 | 频繁删改弱 | 数据仓库、BI |
| Cassandra | 宽列 | 极大规模写入 | 灵活查询受限 | 海量日志、多数据中心 |
你现在就可以用的选择逻辑
按业务场景走：
- 核心业务要事务、关系复杂 → PostgreSQL（新项目首选）/ MySQL（团队求稳）
- 要缓存、会话、实时计数 → Redis
- 数据模型天天变、要横向扩展 → MongoDB
- 要做站内搜索、日志分析 → Elasticsearch
- 报表、BI、海量分析 → ClickHouse
- 数据大到关系库扛不住、全球分布 → Cassandra
- 做 AI 语义检索 → PostgreSQL + pgvector 起步，不够再上 Milvus
最后一条铁律：真实系统几乎都是多数据库混用的。 前端用 Redis 扛缓存，核心业务 PostgreSQL 存数据，日志丢 Elasticsearch / ClickHouse 做分析——“一种数据库打天下”的想法，别在架构设计里出现。
数据库选型从来不是单选题，而是”每个环节选对工具”的组合题。搞懂每个库的性能上限和瓶颈在哪，你就能在架构评审时说出”为什么这里用这个”，而不是”因为大家都这么说”。