EXPLAIN看到EXPRESS_IXSCAN说明已启用MongoDB 8.0的索引加速路径，即单集合、单$match、有可用索引且无复杂操作时绕过传统计划器，实现毫秒级响应。
EXPLAIN 看到 EXPRESS_IXSCAN 就说明用上了新加速
MongoDB 8.0 引入了 EXPRESS 执行阶段，它不是新语法，而是查询优化器在满足条件时自动启用的底层加速路径。当你在 explain("executionStats") 输出里看到 EXPRESS_IXSCAN 或 EXPRESS_CLUSTERED_IXSCAN，就代表这个聚合的 $match 阶段已绕过传统查询计划器，直接走索引快速路径——响应时间可能从秒级压到毫秒级。
触发条件很具体：
- 必须是单集合、单 $match（不能有 $lookup / $unwind 等前置依赖）
- $match 条件字段上要有可用索引（复合索引也支持）
- 不能含聚合表达式（如
$expr、$where）或数组操作符（$elemMatch在某些场景会禁用） - 查询需落在
find语义子集内（即等值 + 范围 + 存在性判断）
$group 不再是纯阻塞阶段，内存压力明显降低
8.0 对 $group 做了底层调度重构：它现在能配合流式输入做部分预聚合，而不是强制等全部数据进来才开始计算。这对大结果集尤其明显——以前查 1000 万行分组，内存峰值可能飙到 4GB；现在同量级下常稳定在 800MB 以内。
但注意：这不改变语义，也不自动排序。如果你依赖 $group 后紧跟 $sort，仍要单独写 $sort 阶段；且 $group 输出顺序仍是未定义的。
实际影响点：
- 允许更激进地提前
$match—— 即使后续有$group，也不必担心“全量加载再过滤” -
allowDiskUse: true触发阈值变高，磁盘落盘频率下降 - 分片集群中，
$group的中间结果序列化开销减少，跨分片 shuffle 更轻量
聚合管道自动重排逻辑更激进，$project 不再“白加”
老版本里，你在 $match 后加个 $project 只选几个字段，数据库未必真提前裁剪——有时还是把整文档传给下一阶段。8.0 的优化器会主动把 $project 的字段裁剪逻辑“下沉”到存储层读取环节，哪怕你没把 $project 放最前面。
这意味着：
- 不必刻意调整
$project位置来“优化”，系统自己会推导 - 但如果你在
$project里用了$addFields计算新字段，再跟$match过滤该新字段——这个$match依然无法下推，因为计算依赖投影结果 - 真正省的是 I/O 和网络传输量，不是 CPU；对 SSD 存储效果比 HDD 明显
分片键无关迁移让聚合不再卡在“搬数据”上
8.0 支持在没有分片键的情况下把集合迁入分片集群（sh.addShardToZone + moveChunk 组合放宽）。这对聚合性能是间接但关键的提升：以前为支持高频聚合，必须提前设计分片键；现在可以先跑单机，等数据量上来再平滑分片，且迁移过程不阻塞聚合查询。
不过要注意：
- 迁移后，如果聚合没带分片键过滤，仍会广播到所有分片——这不是 8.0 解决的问题
- 新分片策略（如哈希分片）对
$lookup关联效率影响很大，得结合业务字段重新评估 -
mongos路由层在 8.0 对聚合返回结果的合并逻辑有微调，偶发小数据集排序错乱，建议加显式$sort
真正容易被忽略的是：EXPRESSION 加速只对“简单 $match”生效，而线上聚合往往裹着 $lookup、$unwind、复杂 $project——这些一加，EXPRESS 就自动退回到经典引擎。别只看版本号，得用 explain 实锤每个查询走哪条路。
