MongoDB 7.0 实现业务写入不中断、聚合查询免序列化、跨分片读取时间点对齐、大批量操作自动分批。这些优化源于资源隔离、Slot-Based引擎、atClusterTime机制和可扩展操作等底层重构，且默认生效。
sh.shardCollection()不再卡住写入
7.0 的初次分片真正做到了“业务写入不中断”，不是靠提速，而是靠资源隔离。旧版本（4.4–6.0）执行 sh.shardCollection() 时，索引重建、chunk 拆分、均衡器迁移三件事抢同一把 config server 元数据锁，导致 writeConcern 延迟飙升、insert/update 排队甚至超时。
- 7.0 默认启用 AutoMerger，在初始 chunk 切分阶段主动抑制“过早分裂”——比如发现某 chunk 写入量极低，就暂缓拆分，减少无效元数据压力
- WiredTiger 引擎在后台 compact 和索引构建时，自动降低 eviction 线程优先级，保障前台 insert/update 不被饿死
-
analyzeShardKey支持readWriteDistribution: true，能提前暴露写热点（比如时间戳字段导致 95% 写入集中到单一分片），避免分片后才发现问题
聚合查询执行不再反复序列化
7.0 的 Slot-Based 查询引擎对含 $lookup、$group、$sort 的聚合管道效果最明显，核心是改掉了“每阶段输出完整文档”的老模式。
- 旧引擎：$group 输出带全部字段的文档流 → $project 再删字段 → 反复序列化/反序列化，中间结果体积大
- 新引擎：只传“槽”（slot），比如
user_id值或$sum(amount)结果，不带无关字段，内存占用可降 40%+ -
$lookup性能提升 30%~50%，但前提是被关联集合有索引（如{ foreignField: 1 }），否则加速无效 - 不支持的写法（如嵌套
$function）会自动回退到旧引擎，并在日志记"Query execution using legacy engine"
跨分片读取终于能对齐时间点
旧版本跨分片查询常出现“时间旅行”：不同 shard 返回的数据来自不同时间点，聚合结果不准。7.0 引入 atClusterTime 机制，强制所有 shard 返回不晚于该逻辑时间戳的数据。
- 协调节点（mongos）为查询分配全局一致的逻辑时间戳，并下发给所有参与分片
- 每个 shard 用 WiredTiger 的多版本并发控制（MVCC）保证返回 ≤ 该时间点的数据
- 这对金融报表、实时 BI 仪表盘至关重要；但注意：它只保证“不晚于”，不保证“精确等于”
- 若某分片落后太多（如 oplog 堆积），可能触发
ReadConcernMajorityNotAvailableYet错误，需检查该 shard 的复制延迟
超大数据集操作不再需要手写分批逻辑
7.0 的可扩展操作（Scalable Operations）让 updateMany、deleteMany 等能透明处理远超 16MB 限制的数据集，开发者不用再自己切 batch、重试、状态跟踪。
- 内部自动分批执行，单分片内保证原子性（全成功或全失败），跨分片仍需显式开启多文档事务
- 所有批次在一致快照下执行，避免中间状态污染
- 有序执行可选（通过
ordered: false关闭），但默认保持顺序 - 注意：
findAndModify同样受益，但涉及$setOnInsert或复杂 upsert 逻辑时，仍需验证最终语义是否符合预期
internalQueryForceClassicEngine: true 或 electionTimeoutMillis 固定值），反而会绕过所有改进。 
