MongoDB 适合存什么：几个典型场景

MongoDB 的文档模型，本质是同一批查询结果里，每条记录的字段可以各不相同。理解了这一点，它适合存什么、不适合存什么，就都好判断了。 文档模型的直觉 MongoDB 的记录叫文档，结构类似 JSON：商品 A 有颜色和尺码字段，商品 B 多一个内存参数，直接各存各的，不用像关系型数据库那样先定死表结构、再用空字段或子表去凑。字段结构变化频繁、嵌套层级深的业务数据，用它写起来省事。对应到表设计上，意味着不用为每个变化反复改结构，写入口径稳定，读的时候按文档整体取。 几个典型场景 日志与行为数据：写入量大、结构随版本演进、基本只增不改。按时间分集合存放，再配一个 TTL（生存时间）索引让旧数据自动过期： db.logs.createIndex({ "time": 1 }, { expireAfterSeconds: 2592000 }) 一行配置，三十天前的日志自动清理，定时任务都不用写。 商品与内容数据：不同品类的字段差异大，文档直接映射页面结构，改版加字段不用动全表，也没有漫长的 ALTER 流程。 用户画像与埋点：维度多、单个字段价值密度低，用嵌套文档把一个对象的全部信息一次读出，省去多次拼装。 事务与关联的短板 跨多张表频繁关联、强事务一致的场景，关系型数据库仍是更稳的选择。MongoDB 4.0 起支持多文档事务，但复杂事务的表现和成熟度跟 MySQL 这类引擎比仍有差距。设计上优先把"经常一起读写的数据放进同一个文档"，从源头减少事务需求；如果业务里出现大量跨文档关联再聚合的查询，说明建模思路还停在关系库，先重新设计文档结构，再考虑换不换工具。 一句建议 选 MongoDB 的理由应该是"数据形状多变、写入量大、按对象整体读取"，三条都占才值得上；只占第一条的，先把关系表结构设计好再说。