MongoDB 不适用场景的具体案例分析

1. 金融核心交易系统（强事务 + 数据一致性要求极高）

业务案例：银行转账、证券交易、支付清结算系统

• 核心需求：

  1. 转账操作必须满足 ACID（原子性、一致性、隔离性、持久性），比如 A 账户扣钱和 B 账户加钱必须同时成功或同时失败，不能出现单边账。

  2. 数据绝对不能丢失，且需要严格的事务回滚、锁机制保障一致性。

• MongoDB 的问题：

  • 虽然 MongoDB 4.0 + 支持多文档事务，但事务性能远低于 MySQL 等关系型数据库，且仅支持单分片内的事务，跨分片事务仍不支持。

  • 金融级别的 “分布式事务”“长事务”“事务隔离级别精细控制”（如 Serializable）MongoDB 无法满足，极易出现数据不一致。

• 反面案例：

  某小型支付公司初期为了 “高性能” 用 MongoDB 做转账核心库，某次系统峰值时，出现了用户 A 扣款成功但用户 B 未到账的单边账，且 MongoDB 无法快速回滚和核对，最终花费数小时人工对账修复，造成用户投诉和资金风险，后续紧急替换为 MySQL。

2. 复杂多表关联查询的业务系统

业务案例：电商订单全链路查询系统（订单 + 用户 + 商品 + 物流 + 支付）

• 核心需求：

  1. 需频繁关联查询：比如 “查询近 3 个月内，上海地区购买过手机类商品、且使用微信支付的用户订单，同时展示物流状态”。

  2. 需支持多表的复杂 JOIN、子查询、分组统计。

• MongoDB 的问题：

  • MongoDB 的关联查询（$lookup）本质是 “客户端侧的关联”，性能远低于 MySQL 的原生 JOIN，数据量稍大（如百万级订单）就会出现查询超时。

  • 多层嵌套的关联查询（如订单→用户→用户地址→用户优惠券）在 MongoDB 中实现复杂，代码可读性差，且性能呈指数级下降。

• 反面案例：

  某电商平台用 MongoDB 存储订单、用户、商品、物流数据，初期数据量小时无问题，当订单量达到千万级后，“按地区 + 商品类型 + 支付方式查订单” 的查询耗时从几十毫秒飙升到数秒，甚至超时。最终将核心查询场景的数椐同步到 MySQL，仅用 MongoDB 存储订单详情的非结构化字段（如用户备注、商品快照）。

3. 数据结构固定且需严格 Schema 约束的场景

业务案例：财务报表系统、税务申报系统、企业 ERP 核心数据

• 核心需求：

  1. 数据字段固定且不可随意变更（如财务报表的 “营收、成本、利润” 字段必须存在且类型固定）。

  2. 需严格的字段约束（如金额必须是数值型、日期格式必须规范、非空字段不能缺失）。

  3. 需支持数据校验、字段级权限控制。

• MongoDB 的问题：

  • MongoDB 的无 Schema 特性是 “双刃剑”，开发人员可能误操作插入字段名错误（如把 “营收” 写成 “营收入”）、类型错误（金额存成字符串）的数据，且无内置的强约束机制，极易导致数据混乱。

  • 财务数据需要审计追踪，MongoDB 的日志和数据变更溯源能力远不如关系型数据库完善。

• 反面案例：

  某中小企业用 MongoDB 存储财务凭证数据，因开发人员疏忽，部分凭证的 “金额” 字段被存为字符串（如 "1000"），部分存为数值（1000），月末统计利润时，因类型不统一导致计算错误，且无法快速定位错误数据，最终替换为 PostgreSQL，通过字段类型约束避免了此类问题。

4. 高并发的 OLAP 分析场景（海量数据复杂统计）

业务案例：大型零售企业的年度销售分析（按地区、品类、时间、客户等级多维度统计）

• 核心需求：

  1. 需对亿级数据进行多维度聚合、排序、钻取分析。

  2. 需支持复杂的统计函数（如同比、环比、占比）和临时报表生成。

• MongoDB 的问题：

  • MongoDB 的聚合管道（Aggregation Pipeline）适合简单统计，但面对多维度、多层级的复杂 OLAP 分析，性能极差，且语法复杂，难以实现灵活的报表逻辑。

  • 缺乏专门的 OLAP 优化（如列式存储、预计算、分区表），远不如 ClickHouse、Greenplum 等 OLAP 数据库高效。

• 反面案例：

  某零售企业用 MongoDB 存储全年销售数据（约 5 亿条），当需要统计 “各省份各品类的月度销售额同比” 时，单次查询耗时超过 30 分钟，且占用大量 MongoDB 资源，导致前端业务读写卡顿。后续将分析数据同步到 ClickHouse，相同查询仅需数秒完成。

5. 需严格权限控制 + 审计的政府 / 企业合规系统

业务案例：政府政务数据管理系统、医疗病历系统

• 核心需求：

  1. 需字段级 / 行级权限控制（如普通员工只能看本部门数据，管理员可看全部）。

  2. 需完整的操作审计日志（谁、何时、修改了哪条数据），满足合规要求。

• MongoDB 的问题：

  • MongoDB 的权限系统仅能到 “集合级”，无法实现精细的字段级 / 行级权限控制，需大量自定义代码实现，成本高且易出漏洞。

  • 审计日志功能薄弱，无法完整追踪每一次数据的增删改操作，难以满足政府 / 医疗行业的合规审计要求。

• 反面案例：

  某地方医疗系统尝试用 MongoDB 存储电子病历，因无法实现 “医生仅能查看自己接诊患者的病历，管理员可查看但不可修改” 的权限控制，且无法追溯病历的修改记录，最终不符合医疗数据合规要求，替换为 Oracle。

总结

1. MongoDB 绝对不适合强事务、高一致性场景（如金融转账），这类场景优先选 MySQL/Oracle 等关系型数据库。

2. 需复杂多表关联查询、严格 Schema 约束的场景（如财务报表、订单全链路查询），MongoDB 的性能和易用性远不如关系型数据库。

3. 高并发 OLAP 分析、精细权限 + 审计的合规场景，应选择专用数据库（ClickHouse、PostgreSQL），而非 MongoDB。