MongoDB 7.0查询性能提升核心是重写底层执行模型：Slot-Based引擎替代树状模型，以槽为单位传递结构化值，降低内存占用、提升$lookup性能30%~50%，并自动回退兼容旧写法。
MongoDB 7.0 的查询性能提升不是靠“加功能”堆出来的，核心是底层执行模型被重写——Slot-Based Query Execution Engine 替换了旧的树状执行器。它对聚合管道中含 $group、$lookup、$sort 的场景影响最直接，不是所有查询都快，但你常写的那几类慢聚合确实变快了。
Slot-Based 引擎到底怎么降低开销
旧引擎每阶段输出完整文档（含大量冗余字段），反复序列化/反序列化；新引擎以“槽（slot）”为单位传递结构化值——比如只传 user_id 字段值或 $sum(amount) 的计算结果，不带无关字段。
- 内存占用下降明显，尤其在
$group后接$project或$addFields时，中间结果体积可减少 40% 以上 -
$lookup左连接性能提升约 30%~50%，但前提是被关联集合有索引（如{ foreignField: 1 }），否则加速无效 - 不支持该引擎的写法（如某些嵌套
$function或自定义 JS 表达式）会自动回退到旧引擎，并在日志里记一条警告："Query execution using legacy engine" - 无需手动开关，启用由查询形状和服务器参数控制；但若误设
internalQueryForceClassicEngine: true，可能触发错误执行计划
explain("executionStats") 看什么才反映真实瓶颈
在分片集群中，explain 默认只显示单个分片的统计，容易误判。真正关键的是 executionStages.shards 下各分片的 executionTimeMillisEstimate 分布。
- 如果某一分片耗时远高于其他（比如 1200ms vs 其余均 ≤200ms），说明数据分布不均或该分片负载过重，不是查询本身问题
- 看到
stage: "SHARD_MERGE"是正常现象，但若伴随高docsExamined或keysExamined，说明下推失败，大量数据被拉到 mongos 合并 -
totalDocsExamined显著大于nReturned，大概率缺索引或索引未覆盖查询字段
analyzeShardKey 输出里哪些字段真要盯紧
analyzeShardKey 不是看个 keyCharacteristics.monotonic 就完事的。它基于真实采样，重点得看分布与广播风险。
-
imbalancedChunks> 5%：说明即使用了哈希，chunk 数据量仍偏差大，可能因字段实际区分度低（如company_id实际只有几十个值） -
broadcastOperations非零：意味着某些常见查询（如find({create_time: {$gt: ...}})）无法路由到单分片，会广播到全部分片，性能雪崩 -
readWriteDistribution比keyCharacteristics更重要——它反映真实读写倾斜，比如写入集中在最近 3 个 chunk，就是热点信号 - 执行时必须用
db.adminCommand，且sampleSize建议 ≥ 10000；别同时设sampleRate和sampleSize，后者优先
Slot-Based 引擎带来的性能收益很实在，但它的生效前提很具体：聚合结构得“规整”，索引得“贴身”，分片键得“能路由”。很多人调完发现没提速，问题往往不在引擎本身，而在这些前置条件漏了一环。
