MongoDB
用 JSON 文档存数据，schema 灵活、开发快
MongoDB 把一条记录存成一个 BSON 文档，字段可以随时加、可以嵌套数组和子文档。它不像 MySQL 那样先建表定字段，特别适合需求变化快、结构不统一的场景，比如商品属性、内容管理、用户画像。
它解决什么问题
商品有 20 个品类，每个品类的属性都不一样；用 MySQL 要么加几十个空列，要么搞 EAV 竖表，查询写得想哭。
真实场景：典型场景：一个商品文档里直接嵌套规格、SKU、图片列表，一次查询拿到全部数据，不用 JOIN 五张表。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
写入、副本同步与分片路由
← 左右滑动查看完整流程图 →
应用带分片键 userId=1024 发起写入，请求先到 mongos。
提示：写永远走 Primary，读可以从 Secondary 读；分片键决定数据去哪个分片。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- schema 灵活，字段随时加，迭代快
- 嵌套文档一次查询拿到完整对象，减少 JOIN
- 副本集自动选主，分片横向扩展
- 聚合管道表达力强，适合做数据加工
- 多文档事务能力弱于 MySQL（4.0 起支持但性能有限）
- 关联查询（$lookup）性能差，不适合强关系模型
- 分片键选错会导致热点，后期改分片键非常痛苦
- 内存消耗大，索引占空间多
常见使用场景
每个场景都配一句「为什么用它」。
商品与内容管理
不同品类商品字段差异大，用嵌套文档一次存全。
为什么用它：避免宽表空列和 EAV 竖表，读写都更直接。
用户画像与日志
把用户行为事件按文档写入，按 userId 分片。
为什么用它：写入量大、结构多变，文档模型天然合适。
物联网设备数据
设备上报的 JSON 直接入库，按 deviceId 分片。
为什么用它：免去 ETL 转换，写入吞吐高。
同类对比
和同赛道的组件并排看，差异一目了然。
多数公司是混用：交易数据在 MySQL，商品详情和日志在 MongoDB。别为了「不用改表」把账务数据放进文档库。
常见问题
上手第一个月最容易卡住的地方。
Q1和 MySQL 怎么选？
数据关系强、要事务和复杂 JOIN、账务类，选 MySQL；结构不固定、以单文档为中心、需要快速迭代和水平扩展，选 MongoDB。很多系统是混用的：交易在 MySQL，商品详情和日志在 MongoDB。
Q2副本集怎么工作？
一主多从，主节点接收写并写 oplog，从节点拉取重放。主节点挂掉后，剩余节点投票选出新主（多数派原则），一般 10~30 秒完成切换。
Q3分片键怎么选？
要满足三点：高基数、写入分布均匀、常用查询条件。范围分片适合范围查询，哈希分片写入更均匀。分片键一旦选定基本不能改，要提前想清楚。
Q4为什么我的查询没走索引？
用 explain("executionStats") 看 COLLSCAN。常见原因：查询条件顺序与复合索引不一致、用了 $ne/$regex 等低效操作符、数组字段没建多键索引。