从关系型到 NoSQL，从内存缓存到搜索引擎，每种数据库都在特定的场景中闪闪发光。对比 8 种主流数据库的核心理念、性能表现和适用场景，帮助你做出最合适的技术选型。
| 数据库 | 类型 | ACID | 查询语言 | 性能 | 扩展性 | 适用场景 |
|---|---|---|---|---|---|---|
MySQL |
关系型 (RDBMS) | SQL | ||||
PostgreSQL |
关系型 (ORDBMS) | SQL + JSON/全文搜索 | ||||
MariaDB |
关系型 (RDBMS) | SQL | ||||
SQLite |
嵌入式关系型 | SQL | ||||
Redis |
内存 KV / 缓存 | RESP 协议 + Lua | ||||
MongoDB |
文档 NoSQL | MQL (JSON-like) | ||||
Elasticsearch |
搜索 / 分析 | RESTful + Query DSL | ||||
ClickHouse |
列式 OLAP | SQL 扩展 |
每张卡片先看类型与 ACID 支持定「能不能用在主库」，再看扩展性与场景定「怎么用」——没有全能选手，只有合适的分工。
数据库选型首先看负载模型：事务、分析、搜索、缓存、文档、日志与实时看板的需求完全不同。
| 场景 | 优先选择 | 常见组合 | 关键指标 | 避坑 |
|---|---|---|---|---|
| 订单/支付/库存 | MySQL / PostgreSQL | 主库 + Redis 缓存 | 事务、锁、主从延迟、恢复时间 | 不要用 Redis/ES 承担强事务主库 |
| 报表分析 / OLAP | ClickHouse | Kafka + ClickHouse | 列存压缩、写入吞吐、聚合延迟 | 不适合频繁小事务更新 |
| 全文搜索 | Elasticsearch | PostgreSQL/MySQL + ES | 召回率、索引刷新、分片大小 | ES 不是事务数据库 |
| 热点缓存 | Redis | DB + Redis + MQ | 命中率、内存、淘汰策略、雪崩保护 | 持久化不等于强一致 |
| 灵活文档 | MongoDB | MongoDB + Redis | 文档模型、索引、聚合管道 | Schema-free 不等于无规范 |
| 嵌入式/本地存储 | SQLite | App + SQLite | 文件锁、备份、迁移脚本 | 不适合多写高并发服务端 |
强调事务一致性、低延迟点查、索引命中和锁控制，适合业务主库。
强调批量写入、列式压缩、复杂聚合和扫描吞吐，适合报表分析。
用内存换延迟，关注过期策略、击穿/穿透/雪崩和热点 Key。
强调分词、相关性排序、倒排索引和近实时检索，不适合强事务。
适合对象结构变化快、嵌套数据多的业务，但仍需字段规范与索引设计。
典型交易系统：MySQL 负责事务，Redis 缓存热点。注意缓存一致性与失效策略。
结构化数据在 PG，复杂全文检索同步到 ES。注意 ES 索引重建和最终一致性。
日志/行为实时分析常用组合。注意批量写入、分区设计和冷热数据管理。
不要把 Redis 当唯一主库；不要用 ES 做资金流水；不要让 SQLite 承担多写服务端并发。
六大典型数据场景的首选与备选。时序与图属于本页 8 款之外的延伸选型，列出供组合架构参考。
| 场景 | 首选 | 备选 | 选择理由 |
|---|---|---|---|
| 缓存 / 会话 | Redis | Memcached、KeyDB | 数据结构丰富、微秒级延迟、客户端生态最广 |
| 文档存储 | MongoDB | PostgreSQL JSONB、Couchbase | 文档模型灵活、分片开箱即用；字段能规范时 JSONB 更省一套运维 |
| 关系 / 事务 | MySQL 或 PostgreSQL | MariaDB、TiDB（超大规模） | 事务与生态最成熟；PG 约束与查询能力更强，MySQL 人才储备更充足 |
| 全文搜索 | Elasticsearch | OpenSearch、Meilisearch（轻量） | 倒排索引 + 分词相关性排序成熟；轻量场景可用嵌入式方案 |
| 时序数据 | ClickHouse / TDengine | InfluxDB、Prometheus（监控指标） | 列存压缩比高、写入吞吐大；监控指标场景 Prometheus 生态更贴合 |
| 图关系 | Neo4j | NebulaGraph、JanusGraph | Cypher 查询直观、多跳性能好；超大规模分布式可选 NebulaGraph |
选型不只看功能匹配，还要评估团队要为它付出多少学习与运维成本。
| 数据库 | 学习成本 | 运维复杂度 | 云托管成熟度 | 社区活跃度 |
|---|---|---|---|---|
| MySQL | 低（SQL 标准入门） | 中（主从 / 分库分表需经验） | 高（各大云均有成熟 RDS） | 很高，资料最全 |
| PostgreSQL | 中（功能面广） | 中 | 高（主流云 + 专项托管） | 很高，版本迭代快 |
| MariaDB | 低（MySQL 迁移友好） | 中 | 中（部分云支持） | 中，社区规模小于 MySQL |
| SQLite | 极低 | 极低（零配置） | —（嵌入应用内，无需托管） | 高，文档质量极佳 |
| Redis | 低（命令简单） | 中（持久化 / 集群 / 大 Key 治理） | 很高（云厂商标配） | 很高 |
| MongoDB | 中（聚合管道需练习） | 中高（分片集群调优） | 很高（Atlas 官方托管） | 高 |
| Elasticsearch | 高（DSL 与分片模型） | 高（JVM 调优、分片规划） | 高（Elastic Cloud 等） | 高，许可变更需关注 |
| ClickHouse | 中高（引擎族概念多） | 中高（合并 / 分片 / 副本运维） | 中（可选云服务较少） | 高，演进非常快 |
真实系统几乎都是多库组合：让每种数据库只做它最擅长的事，再用同步机制把它们串起来。
唯一写入权威，承载事务与强一致数据，所有变更先落主库。
缓存热点读结果、会话与计数器；失效策略与缓存一致性是核心课题。
承接复杂条件搜索与日志分析，数据由主库异步同步，允许秒级延迟。
只有 MySQL 可作为强一致写入源；Redis / ES 上的数据必须可随时重建。
基于 binlog / WAL 订阅变更（Debezium / Canal），对业务代码零侵入，是首选方案。
代码同时写两个库，实现简单但要面对不一致窗口，必须配合对账补偿。
批量抽取-转换-加载，适合报表与离线分析，容忍小时级延迟。
低延迟选 CDC、可容忍偏差选双写、离线分析选 EL；无论哪种都要有对账任务兜底。
容量评估和成本测算不必精确到个位，但要有量级感：这张表帮你快速校准经验值，避开「2000 万行必须分表」这类机械结论。
| 对照项 | 经验值 / 量级 | 结论与反驳 |
|---|---|---|
| 单表 2000 万行 | 经验值的来源：按行较大 + B+ 树 3 层高度的早期估算 | 不要机械套用——行窄、内存充足时 5000 万～1 亿照样能跑；真正的红线是 B+ 树层数涨到 4 层、缓冲池命中率下滑 |
| 内存能装下热数据吗 | InnoDB 缓冲池命中率 > 99% 为健康线 | 热数据小于 buffer pool 时性能最好；命中率跌破 95% 说明内存不够或索引设计差，加内存比加机器更先见效 |
| SSD 与内存价格 | 每 GB 内存约为 NVMe SSD 的 10～30 倍 | 结论：用 SSD 扩容量、用内存保热数据；随机读密集场景优先砸内存，顺序扫描 / 冷数据放 SSD 足够 |
| 云托管 vs 自建 | 云托管总价常为自建云盘成本的 1.5～3 倍 | 成本项逐项比：实例 + 存储 + 备份 + 流量 + 高可用 + DBA 人力；团队无专职运维时云托管隐性更省，规模化后自建或混部更划算 |
| 备份存储倍数 | 备份存储常达数据量的 2～5 倍 | 全量 + 增量 + 多版本保留 + 异地容灾逐层翻倍；预算容量时先算保留期与副本数，再谈去重压缩能省多少 |
换库、上云、分库分表都算迁移：开工前先过一遍这 6 项，任何一项答不上来都说明方案还没准备好。
| 决策项 | 判断标准 | 应对方案 |
|---|---|---|
| 数据量与迁移窗口 | 全量导出导入耗时估算 + 业务可接受的中断时长 | TB 级用物理复制 / 快照克隆而非逻辑导出；数据量大到窗口装不下，就走「全量同步 + 增量追平」不停机方案 |
| 停机窗口 | 能否接受分钟级只读或停写 | 能接受则「停写 → 追平 → 切读」最简单；不能接受则必须 CDC 双跑 + 原子切换域名 / 配置，演练两次再上线 |
| 双写风险 | 双写期间任一侧失败都会产生不一致 | 以旧库为准、新库异步补写；写失败要落补偿队列重试；绝不让双写变成「两侧都成功才算成功」的分布式事务 |
| 回滚方案 | 切换后多久内还能一键回退 | 反向同步先行：新库写回旧库的链路要先验证；回滚窗口期内旧库保持可写，过期后回滚成本陡增，要把窗口写进预案 |
| 一致性校验工具 | 行数、抽样、全量 checksum 三级校验 | MySQL 用 pt-table-checksum / pt-table-sync，跨异构库写对账任务按主键分块比对；校验通过才能切流 |
| 灰度切流 | 按比例、按租户 / 用户维度逐步放量 | 1% → 10% → 50% → 100%，每档观察错误率与延迟；读先切、写后切，出问题只回滚受影响的那部分流量 |
