别再乱选数据库！MySQL/Redis/MongoDB/HBase/Neo4j 等 5 类数据库 + 10 + 实战案例

下面按「关系型数据库+4类非关系型数据库」分类，整理核心特点、适用场景及差异化demo（覆盖电商、金融、医疗、IoT、社交等10+不同领域），确保每个场景都能体现对应数据库的核心优势：

一、关系型数据库（代表：MySQL、PostgreSQL）

核心特点

• 基于「表结构」存储数据，严格遵循 ACID事务（原子性、一致性、隔离性、持久性）；
• 支持复杂表关联（JOIN），适合「结构化数据+强约束」场景。

适用场景描述

需保证数据绝对一致性（如交易、财务）、数据格式固定（字段无动态变化）、需简单表关联（1-2跳）的业务。

demo场景举例

1. 电商订单管理系统

   • 业务：用户下单后，需同步生成「订单表」「订单明细表」「支付记录表」，确保“付款成功→订单生成→库存扣减”三步原子执行（缺一不可）。
   • 为什么用：MySQL的ACID事务能避免“付款了但订单没生成”“订单生成了但库存没扣”的异常，表关联（订单表JOIN用户表）可快速查“某用户的所有订单”。

2. 银行转账系统

   • 业务：用户A向用户B转账1000元，需扣减A的余额、增加B的余额，且两步必须同时成功或同时失败。
   • 为什么用：强事务一致性是核心——若中途系统崩溃，MySQL会回滚所有操作，不会出现“A的钱扣了但B没收到”的情况，这是所有非关系型数据库都无法替代的。

3. 学校教务管理系统

   • 业务：存储「学生表」「课程表」「选课表」，需查询“某学生选的所有课程及任课老师”（学生表JOIN选课表JOIN课程表JOIN教师表）。
   • 为什么用：数据格式固定（学生有学号/姓名，课程有课号/学分），1-2跳表关联效率高，且需保证“选课人数不超过课程容量”的约束（MySQL的CHECK或外键可实现）。

二、键值数据库（代表：Redis、Memcached）

核心特点

• 以「键-值（Key-Value）」成对存储，无复杂结构；
• 读写速度极快（内存操作），适合「高频读写+简单数据」场景。

适用场景描述

需缓存高频访问数据（减少数据库压力）、存储简单标识数据（如Token、计数）、需原子操作（如库存扣减）的业务。

demo场景举例

1. 电商首页商品缓存

   • 业务：电商首页“热销商品”访问量极高（每秒10万次），若直接查MySQL会导致数据库崩溃。
   • 为什么用：将热销商品信息（Key：商品ID，Value：商品名称/价格/库存JSON）缓存到Redis，查询时直接读内存，响应时间从MySQL的100ms降至1ms，支撑高并发。

2. 秒杀活动库存计数

   • 业务：秒杀商品库存100件，需支持10万人同时抢购，确保库存不超卖、不重复扣减。
   • 为什么用：Redis的DECR命令是原子操作（同一时间只有一个请求能修改库存），避免“多线程同时读库存=100，都扣减成99”的超卖问题，而MySQL的update会因锁表导致并发拥堵。

3. IoT设备实时状态存储

   • 业务：城市路灯监控系统，需存储10万个路灯的“开关状态”（开/关），支持每秒1万次状态查询和修改。
   • 为什么用：路灯状态是简单的“键-值”（Key：路灯ID，Value：1=开/0=关），Redis的读写延迟仅0.1ms，能实时同步状态，且支持过期清理（如离线设备状态自动失效）。

三、文档数据库（代表：MongoDB、CouchDB）

核心特点

• 以「JSON/BSON文档」存储数据，schema灵活（不同文档可有不同字段）；
• 支持嵌套结构，适合「半结构化数据+无复杂关联」场景。

适用场景描述

数据格式多变（如不同类型商品的属性差异）、需存储嵌套信息（如文章+评论）、无需多表关联的业务。

demo场景举例

1. 电商商品详情页存储

   • 业务：电商平台同时卖“手机”和“衣服”——手机需存储“CPU型号/内存/摄像头”，衣服需存储“尺码/面料/颜色”，字段完全不同。
   • 为什么用：MongoDB的文档可灵活定义字段（手机文档有CPU字段，衣服文档没有），无需像MySQL那样建“手机表”“衣服表”；且支持嵌套（商品文档内嵌套“规格列表”“售后政策”），查询时一次就能获取所有详情。

2. 医疗电子病历系统

   • 业务：存储不同患者的病历——感冒患者的病历有“体温/咳嗽症状”，糖尿病患者的病历有“血糖值/用药记录”，字段差异极大。
   • 为什么用：MongoDB的灵活schema能适配不同病种的病历结构，无需修改表结构；且支持文档版本控制（可追溯病历修改历史），符合医疗数据合规要求。

3. 社交平台用户动态存储

   • 业务：用户发布动态，可包含“文字/图片URL/话题标签/@好友列表”，不同动态的内容类型不同（纯文字、多图、带视频）。
   • 为什么用：用户动态是嵌套结构（动态文档内嵌套“图片数组”“@好友ID数组”），MongoDB可直接存储，查询时一次就能获取动态的所有关联信息，无需像MySQL那样查“动态表+图片表+@关系表”。

四、列存数据库（代表：HBase、Cassandra）

核心特点

• 按「列族」存储数据（而非行），擅长“按列查询”；
• 支持PB级海量数据、高写入吞吐，适合「写多查少+按列统计」场景。

适用场景描述

需存储亿级/ PB级数据（如日志、流水）、查询时仅需部分列（无需整行数据）、写入频率远高于查询频率的业务。

demo场景举例

1. IoT设备日志存储

   • 业务：智能手环每天产生1000万条日志（包含“时间/心率/步数/定位”4列），需存储1年数据（共365亿条），且常需查询“某用户3月份的心率数据”（仅查“时间+心率”两列）。
   • 为什么用：HBase按列族存储，查询“心率数据”时只需加载“心率列”，无需加载“步数/定位”列，IO效率比MySQL（加载整行数据）高10倍；且支持水平扩展（加服务器就能存更多数据），轻松应对PB级日志。

2. 金融交易流水系统

   • 业务：银行每天产生5000万条交易流水（包含“交易时间/金额/账户ID/备注”），需存储5年数据，且常需统计“某账户每月的总支出”（按“账户ID+月份”分组查“金额”列）。
   • 为什么用：Cassandra的列存结构适合“按列统计”，统计时无需扫描全量数据；且写入吞吐极高（每秒可写10万条流水），不会因高峰期交易量大导致写入拥堵。

3. 气象数据存储系统

   • 业务：全国1万个气象站，每10分钟上传一次数据（包含“温度/湿度/降水量/风速”），需存储10年数据（共3.15万亿条），查询时常按“区域+日期”查“温度”列。
   • 为什么用：HBase的“行键=区域+日期”设计，可快速定位某区域某天的数据；按列查询“温度”时仅加载温度列，避免加载其他无关列，查询速度比行存数据库快50倍。

五、图数据库（代表：Neo4j、NebulaGraph）

核心特点

• 以「节点-关系-属性」的图结构存储数据，关系是“一等公民”；
• 支持多跳遍历、路径分析，适合「关系密集+关联推理」场景。

适用场景描述

需分析实体间复杂关系（如3度好友、疾病-药物关联）、需路径优化（如最优物流路线）、关系查询效率优先的业务。

demo场景举例

1. 社交网络好友推荐

   • 业务：用户A需推荐“可能认识的人”，逻辑是“用户A的好友的好友中，共同好友数≥3的人”（3度关系分析）。
   • 为什么用：Neo4j的图遍历可直接从A出发，2跳找到“好友的好友”，并统计共同好友数，查询时间仅需0.5秒；若用MySQL，需3次表JOIN（用户表JOIN好友表JOIN好友表），百万级用户时查询会超时。

2. 医疗知识图谱问答

   • 业务：用户提问“治疗高血压的药物有哪些副作用？”，需关联“高血压（疾病）→治疗药物（药物）→副作用（症状）”的3跳关系。
   • 为什么用：Neo4j可通过MATCH (d:疾病 {name:"高血压"})-[:治疗药物]->(m:药物)-[:副作用]->(s:症状) RETURN s.name直接获取结果，无需像MongoDB那样多次查询拼接；且支持关系属性（如“药物副作用的发生率”），可优先推荐发生率低的药物。

3. 金融反欺诈系统

   • 业务：识别“异常交易”——若“用户A→账户B→账户C→账户D”的转账链中，有2个账户曾涉及欺诈，需标记该转账链为高风险。
   • 为什么用：Neo4j可快速遍历“用户-账户-交易”的关系链，1秒内识别5跳内的关联欺诈账户；若用MySQL，需5次表JOIN，百万级账户时查询会耗时几分钟，无法满足实时反欺诈需求。

总结：场景与数据库的核心匹配逻辑

业务核心需求	首选数据库类型	本质原因
数据一致性（交易、财务）	关系型数据库	ACID事务保障数据不异常
高频读写（缓存、计数）	键值数据库	内存操作，读写延迟毫秒级
数据格式多变（商品、病历）	文档数据库	灵活schema，无需固定表结构
海量数据存储（日志、流水）	列存数据库	列族存储，按列查询效率高
复杂关系分析（社交、图谱）	图数据库	原生图结构，多跳遍历效率碾压

每个数据库都不是“万能工具”，而是“场景适配工具”——比如同一电商平台，会用MySQL存订单、Redis存缓存、MongoDB存商品详情、Neo4j做推荐，多库协同才能满足所有业务需求。