那年我们接手了一个日活接近 120 万的社区产品，核心表是 posts 和 comments。原来的架构是 MySQL 8.0，单表数据量在 18 个月左右就冲到了 4500 万行。那时候最头疼的不是写，而是读。社区首页的“热门动态”接口，需要把帖子、作者信息、最近 3 条热评、点赞数、收藏数拼在一起。MySQL 这边就得 JOIN 四张表，再加几个 COUNT 子查询。
平时白天还好，一到晚上 8 点流量高峰，这个接口的 P99 响应时间能跑到 1.2 秒，慢查询日志里全是这个 SQL。DBA 给 posts 表加了联合索引，甚至把 comments 的部分字段冗余进了 posts 表，但效果有限。因为社区内容的结构变化很快，运营今天要加个“话题标签”，明天要加个“地理位置”，每次改表都是一次 DDL 大手术，锁表时间经常超过 30 秒，只能等到凌晨做。
我带着两个后端同事做了两周的验证，最终决定把动态相关的核心数据迁移到 MongoDB 8.0。我们选 8.0 是因为它刚在 2024 年 10 月发布，查询引擎里引入了 Block Processing，对聚合分析的性能提升很明显，而且我们后续打算接 Atlas Vector Search 做内容推荐，8.0 的原生向量支持更完整。
迁移的核心思路很简单：把原来分散在多个关系表里的数据，变成 MongoDB 里的一个文档。比如一个帖子，在 MongoDB 里长这样：
这样做最直接的好处是，原来那个要 JOIN 四张表的查询，现在只需要一次 findOne 或者带简单过滤的 find。我们压测时用的数据量是 5000 万条帖子文档，平均文档大小在 4.2 KB 左右。
压测对比是在同等配置的机器上做的（16C 64G，SSD，无分片，单复制集）。场景是“获取用户时间线”，MySQL 那边是优化过的宽表加索引，MongoDB 是 author.userId 和 createdAt 的复合索引。
这个差距主要来自于两点：一是 MongoDB 的文档模型避免了 JOIN 带来的随机 I/O；二是 8.0 的查询引擎在处理 stats.likeCount > 100 这种过滤时，Block Processing 让 CPU 缓存命中率高了不少，我后来用 explain("executionStats") 看，扫描行数差不多，但 executionTimeMillis 确实降了。
当然，不是所有数据都适合搬过来。我们保留了 MySQL 里的订单、支付、用户账户这些强事务、强一致性的核心数据。MongoDB 这边主要承载的是“读多写少、结构多变、需要高并发查询”的内容流场景。迁移后，原来那个接口再也没出现在慢查询里，而且运营要加新字段，直接在代码里写就行，数据库层面完全无感。
---
很多人一听电商订单，第一反应就是“这必须用 MySQL，事务强一致”。其实不一定。我们去年做的一个垂直电商小程序，SKU 不算太多，但订单状态流转非常复杂，而且经常要改结构。比如原来订单里只有“商品信息”，后来要加“促销分摊”、“优惠券明细”、“物流轨迹快照”，每次改 MySQL 表结构都心惊胆战。
后来我们决定把订单数据迁移到 MongoDB 8.0，但前提是必须解决两个问题：一是订单状态的一致性，二是库存扣减和订单创建的原子性。
MongoDB 从 4.0 开始就支持多文档 ACID 事务，8.0 在这块已经非常成熟。我们当时最担心的是事务性能，毕竟社区里一直有人说 MongoDB 事务开销大。但实际测下来，在复制集环境下，只要事务粒度控制得好，问题不大。
我们订单文档的设计是这样的：把订单主表、订单商品明细、状态变更记录全部内嵌在一个文档里。为什么这么做？因为一次订单查询，99% 的场景都需要这些信息。如果拆成多个集合，就得用 $lookup，性能肯定不如直接读一个文档。
这里有个坑我必须提一下。我们刚开始把 statusLogs 设计成无限增长的数组，结果有个用户半年内下了 200 多单，每单状态变更十几次，导致单个订单文档膨胀到 12 MB。MongoDB 的单个文档大小限制是 16 MB，虽然没爆，但每次更新这个文档的 status 字段，都要把整个 12 MB 的文档从磁盘读出来再写回去，慢得离谱。后来我们改了策略，只保留最近 10 条状态日志，更早的归档到另一个集合 order_status_history 里。
再说说事务。我们最核心的场景是“下单扣库存”。在 MongoDB 里，我们用 Node.js 驱动这么写：
这段代码的精髓在于 session 对象。它把三个操作绑在一起，任何一个失败，前面两个都会回滚。有一次线上出问题，是因为库存集合里某个 SKU 的索引建错了，导致 updateOne 没命中，直接抛了“库存不足”的错误，订单和优惠券都没动，数据一致性保住了。
不过，我建议事务尽量短。我们之前有个同事把“发消息通知”也塞进事务里，结果通知服务抖动，导致事务一直等，最终锁住了库存文档，影响了其他用户下单。后来我们把非核心操作都挪到事务外面，用消息队列异步处理，问题就解决了。
---
我们系统里有个“商家后台数据分析”的功能，商家能看到自己店铺最近 30 天的订单趋势、商品销量排行、退款率这些。数据来源是 orders 集合，现在已经有 2.3 亿条文档了。之前这个功能跑得还行，但随着数据量增长，那个“按天统计订单金额”的接口越来越慢，尤其是在大商家（单月订单 50 万+）的页面上，经常要 3 秒多才能出来。
我排查的时候，第一反应是看索引。orders 集合在 sellerId 和 createdAt 上已经有复合索引了，按理说不应该这么慢。我用 explain 看了一下那个聚合管道：
executionStats 显示，totalDocsExamined 是 51 万，但 executionTimeMillis 高达 3200ms。扫描的文档数虽然被索引控制住了，但 $group 阶段的处理非常慢。我那时候还没升级到 8.0，用的是 7.0。
后来 MongoDB 8.0 发布，我看到 Release Notes 里提到 Block Processing 优化，专门针对聚合管道里的过滤和分组操作。升级过程很平滑，复制集逐个重启节点就行，业务没感知。升级完再跑同一个查询，耗时直接降到了 780ms，提升了 4 倍多。
我仔细研究了一下，Block Processing 的核心是把原来“一行一行处理”的方式，改成了“按块（Block）批量处理”。在 $group 阶段，如果分组键是时间或者范围，8.0 的引擎会尝试把相邻的文档在内存里按块组织，减少哈希表的查找和内存分配次数。对于我们这种按天分组的场景，效果特别明显。
为了验证，我还专门写了一个测试脚本，往测试库里灌了 1000 万条订单数据，然后对比 7.0 和 8.0 的表现：
在 7.0 下，这个聚合平均耗时 1200ms；8.0 下稳定在 310ms 左右。而且我注意到，executionStats 里的 usedBlockProcessing 字段变成了 true，说明优化确实生效了。
不过，Block Processing 不是万能的。我试过在 $group 里用 $addToSet 这种需要维护复杂状态的累加器，优化效果就不明显。还有一次，我在 $match 阶段用了 $or 加多个条件，导致查询优化器没选对索引，Block Processing 也没用上。后来我把 $or 拆成了两个查询再用 $unionWith 合并，性能才回来。
现在我们的数据分析接口，P95 响应时间控制在 400ms 以内，商家反馈“终于不转圈了”。如果你也在跑大量聚合查询，而且数据量在亿级别，升级到 8.0 绝对值得一试，尤其是那些按时间、按类别分组的场景，Block Processing 带来的提升是实打实的。
去年我们团队接手了一个企业知识库问答系统的重构任务。原有的方案是基于关键词匹配，准确率惨不忍睹，用户问“怎么报销差旅费”，系统能返回“差旅费报销单模板下载”。在2024年，这种体验显然无法接受。我们决定引入RAG（检索增强生成）架构，而MongoDB 8.0发布后，其原生支持的Atlas Vector Search成为了我们的首选方案，原因在于它允许我们将向量数据和业务元数据（如文档来源、更新时间、权限标签）存储在同一个文档里，避免了跨库查询带来的延迟和数据一致性问题。
在MongoDB 8.0中，向量搜索不再是附加组件，而是深度集成到了查询引擎中。我们当时使用的是Atlas M10实例，数据集包含约12万篇内部Wiki文档，通过OpenAI的text-embedding-3-small模型生成向量，维度为1536。
场景与实施细节
我们的文档结构如下，除了向量字段，还包含了控制访问权限的allowed_roles：
为什么这么做？ 如果采用传统的“向量数据库+MySQL”组合，当用户发起查询时，我们需要先在向量库检索出Top K个文档ID，再去MySQL中查询这些ID对应的权限信息。这增加了网络往返，且如果向量库和关系库之间的数据同步有延迟，会导致权限泄露。在MongoDB中，这一切都在一次查询中完成。
以下是我们在Node.js后端中执行向量检索的核心代码。注意，这里我使用了$vectorSearch聚合阶段，并结合了权限过滤：
性能与取舍
在8.0版本的测试中，我们在12万条数据量级下，上述查询的P99延迟稳定在110ms左右。如果不做numCandidates的调优，直接拉满到500，延迟会上升到300ms以上，原因在于过多的候选集会增加内存中计算欧氏距离的开销。我们最终权衡后选择了150，既保证了召回率，又控制了延迟。
不这么做会怎样？我见过一些团队为了图省事，直接把向量存进MongoDB但不建向量索引，或者索引类型选错。没有vector类型的索引，MongoDB会进行全表扫描计算距离，12万条数据可能耗时超过2秒，这在实时问答场景中是无法忍受的。
那是去年双十一大促的前一周，我们的核心交易系统突然出现间歇性卡顿。系统架构是标准的微服务，订单服务依赖MongoDB 7.0（后升级至8.0）存储订单详情。当时监控显示，订单列表查询接口的响应时间从平时的50ms飙升到了800ms，数据库CPU使用率一度冲高到90%，QPS却只有可怜的200。
排查过程
我登录了Atlas的监控后台，查看“Slow Query”日志。一条针对orders集合的查询引起了我的注意：
这条查询的逻辑很简单：查找某个用户已发货的订单，并按时间倒序排列。但执行计划（explain()）显示，它扫描了45,000个文档才返回10条结果，扫描/返回比高达4500:1。原因在于，虽然user_id上有索引，但status和created_at没有组合索引。MongoDB在使用了user_id索引后，仍需回表扫描大量数据进行过滤和排序。
解决方案与实施
我当时的判断是必须建立一个覆盖查询条件的复合索引。在MongoDB 8.0中，索引的构建效率已经大幅提升，但我们当时数据量已达800万条，依然需要谨慎操作。我选择在业务低峰期通过后台创建索引，并使用了background选项（虽然8.0中默认行为已优化，但显式声明有助于理解）：
为什么是这种顺序？ 索引键的顺序至关重要。我将user_id放在第一位，是因为它是等值查询；status第二位，也是等值查询；created_at放在最后，用于排序和范围查询。这种顺序能最大化利用B-Tree的有序性，使得排序操作不再需要内存排序（in-memory sort），直接利用索引的有序性返回数据。
索引创建完成后，再次执行explain()，扫描文档数变成了10，查询耗时从800ms降到了12ms。
教训与延伸
这次事故让我深刻意识到，不要迷信MongoDB的“无模式”灵活性而忽略了索引设计。特别是在8.0版本中引入了Block Processing优化，对分析型查询有帮助，但这并不代表你可以忽略基础索引。如果当时不建这个索引，随着数据量增长到千万级，这种查询会直接拖垮整个复制集的主节点，导致故障转移（Failover），那是真正的“生死时速”。
在我的职业生涯中，关于“到底用复制集还是分片集群”的讨论从未停止。很多团队在初期就过度设计了分片集群，结果运维复杂度指数级上升。我的观点很明确：除非单表数据量即将突破2TB，或者写吞吐量超过了单节点硬件的处理极限（例如持续写入超过5K QPS），否则请老老实实使用复制集。
复制集（Replica Set）的实战运维
我们现在的用户中心系统运行在一个三节点的复制集上，版本是MongoDB 8.0。配置上，我坚持使用奇数个节点（3个或5个），原因在于选举机制。MongoDB的选举需要大多数（Majority）节点投票才能选出主节点。3个节点需要2票，5个节点需要3票。如果是4个节点，需要3票，但成本增加了，容错能力却和3节点一样（都只能坏1个），这在成本效益上是不划算的。
在代码层面，配置连接字符串时必须包含replicaSet参数和readPreference，否则你可能读到了旧数据还不知道为什么。
分片集群（Sharding）的选型判断
什么时候该分片？我之前负责过一个物联网（IoT）项目，设备每秒上报数据10,000条，单日数据增量超过20GB。复制集的单个Primary节点写入能力很快成为瓶颈，磁盘I/O常年跑满。在这种情况下，我们迁移到了分片集群。
分片的核心在于Shard Key（片键）的选择。我们最初选了device_id作为片键，结果导致数据分布不均（Jumbo Chunks），因为某些设备上报频率远高于其他设备。后来我们改用了组合片键：{ device_id: 1, timestamp: 1 }。
为什么不这么做会怎样？ 如果片键选择不当（如单调递增的时间戳），所有新数据都会写入同一个分片，造成“热分片”问题，分片集群就退化成了单节点性能。
面试高频考点复盘
在面试候选人时，我常问：“MongoDB复制集发生主节点宕机，数据会丢失吗？”
很多候选人会直接说“不会”。实际上，这取决于Write Concern（写关注）。如果你写入时使用的是默认的{ w: 1 }，即只确认主节点写入就返回，那么主节点宕机且无法恢复时，那些还没同步到从节点的数据就会丢失。解决方案是在关键业务中使用{ w: "majority" }，确保数据被复制到大多数节点后才算成功。
在MongoDB 8.0中，结合ACID事务，这种机制更加可靠。但作为工程师，你必须清楚背后的权衡：强一致性（majority）会带来更高的延迟。我们的支付系统选择了强一致，而用户的操作日志系统则选择了w: 1以换取低延迟。没有银弹，只有适合场景的取舍。
去年我接手了一个本地生活服务的小程序，日活大概在 30 万左右。当时用的是 MySQL，订单表已经膨胀到快 5000 万行，查询速度慢得让人想砸键盘。最头疼的是业务方非要加一个“动态属性”功能，比如不同品类的订单要存不同的扩展字段，MySQL 那几张表被改得面目全非，加字段都要锁表半天。
我狠下心做了迁移，把核心订单链路换成了 MongoDB。
具体怎么干的？
我没有一次性全切，而是先拿“订单日志”和“用户动态”这两个读写比高、结构乱的模块开刀。技术栈用的是 MongoDB 4.4（当时 8.0 还没出），复制集架构。
碰到的真问题：
上线第一周，运营反馈后台查询订单列表偶尔会卡顿。我盯着监控看，发现是 status 和 createTime 的复合索引建得有问题，导致排序时没走索引。还有一次，因为没开 retryWrites，在高峰期网络抖动时丢了几条非核心日志。
解决过程：
我花了两个晚上重构了索引策略，把原来按 MySQL 思维建的窄表索引，改成了贴合业务查询路径的宽索引。对于那个丢数据的问题，直接开启了事务重试机制。最后的效果是，订单查询的 P99 延迟从原来的 800ms 降到了 120ms，而且再也不用因为加字段而提心吊胆了。
* 什么时候真的适合用？ 如果你的数据结构经常变，或者数据增长太快让你觉得分库分表很痛苦，MongoDB 绝对是首选。像我这种订单带动态属性的场景，简直是救星。
* 什么时候别上？ 别为了用而用。如果你做的是那种强一致性要求的财务系统，或者数据关系复杂得像蜘蛛网（比如传统的 ERP），还是老老实实待在 MySQL 或者 PostgreSQL 里吧。我见过有人为了赶时髦把简单的配置表也迁过去，结果连表关联都写得费劲，纯属给自己找事。
* 选型坑： 别以为 MongoDB 不需要设计。我见过有人把所有的东西都塞进一个文档里，导致单个文档巨大无比，性能反而崩了。
学 MongoDB 别光看文档，直接起一个本地实例，把你的 MySQL 数据导进去试试。特别是聚合管道（Aggregation Pipeline），刚开始写会觉得反直觉，但写顺了你会发现比 SQL 的嵌套查询爽太多。别怕犯错，我当年也是把生产库差点搞挂才学会敬畏索引的。