聚合管道本身不加速地理空间计算，但配合地理空间索引、首个$geonear阶段及字段裁剪可显著降延迟；$geonear必须为首阶段以保证排序与字段注入，且依赖2dsphere索引、主节点执行及避免滥用$lookup。
直接结论：聚合管道本身不加速地理空间计算，但配合地理空间索引 + 早期 $geoNear 阶段 + 合理字段裁剪，能显著降低延迟和资源消耗。
为什么 $geoNear 必须是聚合管道第一个阶段
这是硬性限制，不是建议。MongoDB 要求 $geoNear 必须是聚合管道的首个 stage，否则会报错："$geoNear is only valid as the first stage in a pipeline"。原因在于：$geoNear 不仅执行距离计算，还会重排文档顺序（按距离升序），并注入 distance 和 location 字段——这些行为必须在其他操作（如 $match、$lookup）之前完成，否则后续 stage 无法依赖其输出结构或排序保证。
常见错误写法：
db.places.aggregate([
{ $match: { type: "restaurant" } }, // ❌ 错：先过滤再 geoNear，报错
{ $geoNear: { ... } }
])
正确写法：
db.places.aggregate([
{
$geoNear: {
near: { type: "Point", coordinates: [116.4, 39.9] },
distanceField: "dist.calculated",
maxDistance: 3000,
spherical: true
}
},
{ $match: { type: "restaurant" } }, // ✅ 对 geoNear 输出再过滤
{ $project: { name: 1, dist: "$dist.calculated" } }
])
地理空间索引缺失会导致聚合直接退化为全集合扫描
即使用了 $geoNear，如果没有在对应字段上建好地理空间索引，MongoDB 就无法使用球面几何优化，只能暴力遍历所有文档算距离——这在万级数据上可能耗时数秒甚至超时。副本集里主节点压力陡增，从节点同步延迟也可能升高。
必须确认已创建索引：
- 字段类型必须是
Point、LineString或Polygon，且存储为 GeoJSON 格式（不是普通数组） - 索引命令必须用
2dsphere类型：db.places.createIndex({ location: "2dsphere" }) - 不能用
2d索引替代，它只支持平面坐标，不适用于真实地理距离
验证是否命中索引：运行 explain("executionStats")，检查 executionStages.stage 是否为 GEO_NEAR_2DSPHERE，且 nReturned 远小于 totalDocsExamined（理想是相等）。
副本集中读偏好影响 $geoNear 结果一致性
默认情况下，$geoNear 只能在主节点执行（因为需要实时位置与最新数据）。如果你在驱动中设置了 readPreference=secondary，请求会被拒绝，并返回错误："$geoNear requires a primary read preference"。
这意味着你无法靠读从节点来分担 $geoNear 压力——它天然绑定主节点。所以优化方向只有两个：
- 确保主节点硬件资源（CPU、内存、磁盘 IO）足够支撑峰值地理查询 QPS
- 在应用层做缓存（例如 Redis 缓存「某坐标附近500米的商家ID列表」），避免高频重复计算
另外注意：副本集同步延迟（optimeDate 差值）超过几秒时，$geoNear 返回的结果可能不含最新插入/更新的 POI，这不是 bug，而是最终一致性模型下的正常表现。
聚合中混用 $lookup 会放大地理查询代价
比如你想查「附近3公里的餐厅，并关联它们的最新5条评论」。如果直接在 $geoNear 后接 $lookup，MongoDB 会对每个匹配的餐厅发起一次子查询——100 家餐厅 = 100 次独立查询，网络往返 + 从库读取开销叠加，延迟极易突破 1s。
更稳妥的做法是分两步：
- 第一步：用
$geoNear获取 ID 列表（加$limit: 50控制数量） - 第二步：用
find({ _id: { $in: [...] } })批量查主文档，再用一次find({ placeId: { $in: [...] } })批量查评论（应用层合并）
这样把 N 次查询压成 2 次，且可并行，实际延迟通常能压到 200ms 内。聚合管道不是万能胶，该拆就拆。
真正卡住性能的，往往不是聚合语法本身，而是地理索引没建对、读偏好设错、或者误以为 $lookup 能免费关联大量文档——这些点一旦忽略，副本集里看似简单的“查附近”就会变成慢查询元凶。
