MongoDB 8.0 高并发性能取决于文档结构设计、索引覆盖性与写入模式优化：嵌入需规避高频更新大文档，引用更适配高基数子项；复合索引须覆盖查询、排序及范围条件；时间序列集合要求扁平结构与严格时间字段约束。
MongoDB 8.0 的文档模型本身不自动适配高并发，关键在于你如何设计文档结构、配合索引策略与写入模式——尤其在支付、证照核验这类秒级响应场景下，错用嵌入或忽略基数膨胀会直接导致 writeConflict 错误频发、document too large 报错，或聚合阶段延迟飙升。
嵌入 vs 引用：别只看关系类型，要看更新频率和基数
一对多不是嵌入的充分条件。比如“订单+订单项”，若每单平均超 50 条明细且频繁增删（如实时退款、补货），即使总量不大，也应拆到 order_items 集合。原因很实际：
- MongoDB 单文档上限 16MB，但 WiredTiger 实际分配页大小为 4KB，高频更新大文档会引发大量 page split 和内存碎片
-
$push/$pull在高并发下极易触发 write conflict，8.0 虽优化了冲突重试逻辑，但无法消除底层锁粒度限制 - 分片集群中，大文档跨 chunk 移动成本高，
moveChunk操作可能阻塞写入
实操建议：对预计 >20 条子项、且子项生命周期独立（如日志、操作记录、凭证附件）的数据，强制走引用；用 $lookup + pipeline 替代全量嵌入，配合从库读取降低主库压力。
复合索引必须覆盖查询+排序+范围条件，否则 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}，且字段顺序不能颠倒 - 8.0 对
index intersection仍不支持，多个单字段索引无法协同生效
验证方式：用 explain("executionStats") 查看 executionStages.stage 是否为 IXSCAN，且 docsExamined ≈ nReturned；若出现 COLLSCAN 或 docsExamined 远大于 nReturned，说明索引未命中或不完整。
时间序列集合（time-series collection）不是“开箱即用”，得改写写入逻辑
8.0 默认启用时间序列集合的自动分块与压缩，但前提是你的文档结构符合约束：
- 必须含单一时间字段（如
event_time），且类型为Date；不能是字符串或嵌套路径 - 所有时序数据必须扁平化，禁止嵌套数组或深层子文档（如
payload.metrics.cpu不合法，得展平为cpu_usage） - 写入必须用
insertOne/insertMany，不支持updateOne修改时间字段值
支付类业务中，交易流水、风控日志等天然适合 time-series，但要注意：原 transactions 集合若已存在历史数据，迁移需用 mongodump + mongoimport 重构结构，不能直接 convertToTimeSeries —— 该命令仅适用于空集合。
真正卡住高并发落地的，往往不是 MongoDB 8.0 本身，而是把旧模型原样搬进新版本后，没重审写入路径的原子性边界、没重估索引字段的组合逻辑、也没重划时间敏感数据的存储形态。这些地方不动，再快的引擎也跑不起来。
