MongoDB 8.0 在高并发场景下的性能表现，核心取决于文档结构设计、索引覆盖能力以及写入模式优化：嵌入模型要避开高频更新的大文档，引用模型更适合高基数子项；复合索引必须同时覆盖查询、排序与范围条件；时间序列集合则要求扁平化结构和严格的时间字段约束。
MongoDB 8.0 的文档模型并不会天然帮你解决高并发问题，真正影响性能的，仍然是文档结构如何设计、索引策略如何规划、写入模式如何选择。尤其在支付、证照核验等对秒级响应要求极高的业务场景中，一旦嵌入方式选择不当，或忽略了数据基数持续膨胀，问题通常会迅速暴露：writeConflict 频繁出现，document too large 等报错也会随之增加，甚至聚合查询阶段的延迟也会明显上升。
嵌入 vs 引用：不要只看关系类型，更要关注更新频率与数据基数
一对多关系并不意味着一定适合嵌入。以“订单 + 订单项”为例，如果每笔订单平均超过 50 条明细，并且明细经常发生增删改操作（如实时退款、补货），即使整体数据量不算大，也更建议拆分到 order_items 集合中。原因很直接：
- MongoDB 单文档大小上限虽然是 16MB，但 WiredTiger 实际页分配大小为 4KB，高频更新大文档容易带来大量 page split 和内存碎片
$push/$pull在高并发写入场景下非常容易触发 write conflict，MongoDB 8.0 虽然优化了冲突重试机制，但并不能彻底消除底层锁粒度带来的限制- 在分片集群环境中，大文档跨 chunk 迁移成本更高，
moveChunk操作还可能对写入造成阻塞
实战建议：对于预计超过 20 条子项，且子项生命周期相对独立的数据（如日志、操作记录、凭证附件），优先采用引用模型；使用 $lookup + pipeline 替代全量嵌入，并结合从库读取分担主库压力，更适合高并发业务架构。
复合索引必须同时覆盖查询 + 排序 + 范围条件，否则 MongoDB 8.0 的性能优势难以发挥
MongoDB 8.0 查询引擎的性能提升，很大程度上依赖索引是否具备完整“覆盖性”。常见问题是只根据 find() 的过滤字段创建索引，却忽视了聚合管道中的 $match、$sort 以及 $gt/$lt 这类范围条件。
- 例如支付核验中的常见查询：
{status: "pending", create_time: {$gt: ISODate("...")}}，如果只建{status: 1}或{create_time: -1}，通常都无法达到理想效果；更合理的做法是建立{status: 1, create_time: -1}复合索引 - 如果后续查询还需要增加
$sort: {updated_at: -1}，那么索引应继续扩展为{status: 1, create_time: -1, updated_at: -1}，并且字段顺序不能随意调整 - MongoDB 8.0 对
index intersection依然不支持，多个单字段索引不能自动高效协同，因此高并发查询更依赖合理的复合索引设计
验证方法：可通过 explain("executionStats") 检查 executionStages.stage 是否为 IXSCAN，同时确认 docsExamined 是否接近 nReturned；如果出现 COLLSCAN，或 docsExamined 远大于 nReturned，就说明索引未命中，或者索引覆盖并不完整。
时间序列集合（time-series collection）并非“开箱即用”，需要同步调整写入逻辑
MongoDB 8.0 默认支持时间序列集合的自动分桶与压缩，但前提是文档结构必须满足相应约束：
- 必须包含单一时间字段（如
event_time），且字段类型必须为Date；不能使用字符串，也不能是嵌套路径 - 所有时序数据都需要保持扁平化，不能包含嵌套数组或深层子文档（如
payload.metrics.cpu不符合要求，需要展平为cpu_usage） - 写入方式必须采用
insertOne/insertMany，并且不支持通过updateOne修改时间字段的值
在支付类业务中，像交易流水、风控日志这类典型时序数据，天然适合存入 time-series collection。不过有一点必须提前确认：如果原有的 transactions 集合中已经存在历史数据，那么迁移时只能通过 mongodump + mongoimport 的方式重建结构，无法直接使用 convertToTimeSeries 一步完成转换——因为该命令只适用于空集合。
真正限制高并发落地效果的，很多时候并不是 MongoDB 8.0 本身，而是把旧版数据模型原样迁移到新版本后，没有重新审视写入路径的原子性边界，没有重新评估索引字段的组合方式，也没有重新规划时间敏感数据的存储模型。这些关键点如果不优化，再强的数据库引擎也很难跑出理想性能。
