文章目录
- 一、为什么选型这么重要？
- 二、三种数据库的核心定位
-
- [1. MySQL：关系型数据库（强一致、强事务）](#1. MySQL：关系型数据库（强一致、强事务）)
- [2. MongoDB：文档型数据库（高频写、结构灵活）](#2. MongoDB：文档型数据库（高频写、结构灵活）)
- [3. Redis：内存型 KV（极致性能、短期状态）](#3. Redis：内存型 KV（极致性能、短期状态）)
- 三、三者对比总览表
- 四、用"数据特征"反推数据库选择
- 五、结合真实业务场景分析
- 六、生产系统中的经典组合
- 七、常见误区（非常重要）
- 八、总结
在实际后端开发中， MongoDB、Redis、MySQL 几乎是绕不开的三种存储技术。
很多同学在项目中都会遇到一个问题：
这个数据，到底该用哪一个？
本文不从"定义"出发，而是从业务数据特征和真实场景切入，系统梳理三者的定位、适用场景以及选型原则。
一、为什么选型这么重要？
数据库选型一旦错误，后期往往意味着：
- 性能瓶颈
- 数据模型推翻
- 代码大规模重构
- 运维成本陡增
所以选型的关键不是我会哪个，而是：
这个数据"本质上"适合放在哪？
二、三种数据库的核心定位
1. MySQL：关系型数据库（强一致、强事务）
MySQL 的核心优势是：
- ACID 事务
- 强一致性
- 复杂查询（JOIN / 子查询）
- 数据安全性高
一句话总结：
MySQL 适合"钱、订单、核心业务数据"
2. MongoDB：文档型数据库（高频写、结构灵活）
MongoDB 的核心优势是：
- 弱 Schema，结构灵活
- 单文档原子性
- 写性能优秀
- 天然适合行为数据
一句话总结：
MongoDB 适合"用户行为、日志、内容、进度"
3. Redis：内存型 KV（极致性能、短期状态）
Redis 的核心优势是：
- 极高的读写性能
- 丰富的数据结构（String / Set / Bitmap / ZSet）
- TTL / 原子操作
- 幂等、去重、限流能力强
一句话总结：
Redis 适合"缓存、状态控制、幂等、统计"
三、三者对比总览表
| 维度 | MySQL | MongoDB | Redis |
|---|---|---|---|
| 是否内存 | ❌ | ❌ | ✅ |
| 持久化能力 | 强 | 强 | 弱（可配） |
| 写性能 | 中 | 高 | 极高 |
| 事务 | 强 ACID | 单文档 | 无 |
| Schema | 强 | 弱 | 无 |
| 复杂查询 | 强 | 中 | 无 |
| 高频写 | 不适合 | 适合 | 适合 |
| 长期存储 | 适合 | 适合 | 不适合 |
四、用"数据特征"反推数据库选择
在选型时，可以问自己以下几个问题：
1️⃣ 数据是否必须强一致、不可丢？
- 是 → MySQL
- 否 → MongoDB / Redis
2️⃣ 写入是否非常频繁？
- 低频 → MySQL
- 高频（行为、日志）→ MongoDB
- 极高频（计数、状态）→ Redis
3️⃣ 数据结构是否经常变化？
- 稳定 → MySQL
- 经常变化 → MongoDB
- 无结构 → Redis
4️⃣ 是否需要长期保存、可回溯？
- 是 → MySQL / MongoDB
- 否 → Redis
5️⃣ 是否需要复杂查询？
- JOIN / 强统计 → MySQL
- 简单聚合 → MongoDB
- 不需要 → Redis
五、结合真实业务场景分析
场景一：声音播放进度
业务特征：
- 用户 + 声音
- 每 10 秒更新一次
- 需要长期保存
- 不要求强事务
❌ 为什么不用 Redis？
- 内存成本高
- 数据生命周期不可控
- 不适合长期行为存储
❌ 为什么不用 MySQL？
- 高频更新导致行锁
- 表膨胀严重
- Schema 灵活性差
✅ 最优选择：MongoDB
MongoDB 非常适合这种：
"用户行为 + 高频写 + 非强事务 + 长期保存"
场景二：声音播放量统计
业务特征：
- 同一用户 24 小时只算一次
- 需要去重
- 高并发
最佳实践：
- Redis：去重 / 幂等 / 计数
- MQ：异步解耦
- MySQL：最终统计结果落库
六、生产系统中的经典组合
在真实生产环境中，三者通常是协作关系，而不是替代关系：
text
MySQL → 核心业务数据（订单 / 用户 / 金额）
MongoDB → 行为数据（日志 / 播放进度 / 浏览记录）
Redis → 状态控制（缓存 / 幂等 / 去重 / 限流）七、常见误区（非常重要）
❌ 错误用法
- 用 Redis 存长期用户行为
- 用 MySQL 存日志或频繁更新数据
- 把 Redis 当成主数据库
- 用 MongoDB 强行做事务系统
✅ 正确用法
- 钱 → MySQL
- 行为 → MongoDB
- 状态 → Redis
八、总结
数据库选型的本质，是尊重数据的"生命周期和特性"，而不是技术偏好。