MongoDB 与 MySQL 混合架构：什么时候该上 NoSQL

结论：只有当「数据结构天然不固定 + 写入吞吐远超单机 MySQL 舒适区 + 这块业务能容忍放弃跨表事务」三条同时成立时，才值得在 MySQL 之外引入 MongoDB；只要缺一条，就老老实实留在 MySQL，用 JSON 列和索引撑下去。

判断标准不是数据量，而是数据结构是否一致

结论：该不该上 NoSQL，先看同一份数据在不同记录之间的字段是否统一，而不是看数据有多少行。

MySQL 是关系型数据库，数据以「行」存在预定义结构的表里，加字段要 `ALTER TABLE`。MongoDB 是文档数据库，一条记录就是一整个 BSON 文档（类 JSON 的二进制格式），同一个集合里的文档允许字段各不相同。

社区论坛就是典型的关系型场景：帖子有标题、作者、发布时间、版块、状态，字段几乎每篇都齐，还要和用户表、版块表做关联。像 Clara BBS 这类 PHP 论坛系统，环境要求只有 PHP 7.4-8.5 + MySQL 5.7+，而它的悬赏托管冻结、采纳后自动发放、附件交易记账这些动作都依赖跨表事务——这正是关系库的主场，硬换 Mongo 是自找麻烦。

反过来，埋点日志、爬虫抓取的原始报文、第三方 API 返回体，今天多一个字段明天少一个，还带嵌套数组，塞进 MySQL 要么不停改表，要么存一大坨 JSON 字符串。

该上 MongoDB 的三个信号

结论：写入量级、结构漂移、单文档聚合读，命中两条以上再考虑引入。

1. 追加型高写入。每秒数千条以上的日志、消息、行为埋点，MySQL 单主写入会明显吃紧，MongoDB 原生分片让横向扩展路径更短。
2. 结构频繁漂移。MySQL 5.7+ 其实也支持 JSON 列，`ALTER TABLE post ADD COLUMN extra JSON` 就能存；但 JSON 列建不了普通索引（要用生成列或函数索引绕），一旦要按里面某个字段筛选就很别扭。
3. 读模式是「按主键取一整块」。比如打开一篇文章详情、拉一份用户画像，MongoDB 一次查询返回整份文档，省掉 MySQL 里五张表的 JOIN。

四个明确不该上的场景

结论：涉及多表强一致、复杂关联、统计报表，或团队没人运维过副本集，一律别上。

• 需要跨实体原子操作。转账、扣库存、订单加明细必须 ACID 事务（原子性、一致性、隔离性、持久性）。MongoDB 4.0 起副本集支持多文档事务、4.2 起支持分片集群事务，但开销和限制都比 InnoDB 大不少，不是舒适区。
• 需要多维度 JOIN 或聚合报表。`$lookup` 能关联，但表达力和性能都不如 SQL，后台统计需求会越写越痛。
• 数据总量其实不大。单表几百万到千万级，索引建对 MySQL 完全够用。
• 团队没有对应运维能力。副本集、分片、选举、oplog 这些概念，得有人真的踩过坑。

混合架构落地的四条边界

结论：MySQL 归主库，管钱和关系；MongoDB 做派生库，管日志和宽文档，靠异步同步保持最终一致性。

1. 按数据形态分家，不按访问频率分家。热数据不等于该进 Mongo。
2. 事务边界全部留在 MySQL。凡是要能回滚的写操作，绝不拆到两个库。
3. 同步方向单向且可重放。推荐在 MySQL 里落一张 outbox 表（待同步事件表），由定时任务投递到 MongoDB，失败可重试，避免双写不一致。
4. 接受秒级延迟。搜索、推荐、日志能忍受；不能忍受的，就别拆。

一句话决策清单

• 订单、财务、积分、会员、论坛帖子 → MySQL
• 埋点日志、抓取原始报文、IM 消息、内容快照 → MongoDB
• 两边都要 → MySQL 主库 + MongoDB 派生视图 + outbox 同步

混合架构的价值不在于「用了两种数据库」，而在于让每种数据待在最擅长处理它的引擎里。先确认业务真的撞到了 MySQL 的墙，再动手拆；大多数项目在拆之前，缺的只是一个合适的索引。