在MongoDB的地理空间处理能力中，聚合管道（aggregation pipeline）允许我们在服务端完成复杂的数据过滤与统计。当业务场景涉及多个分散区域联合查询，例如某物流系统需要统计包裹落在几个互不相连的城市圈时，使用$multiPolygon比多次$polygon拼接更高效。它本质上是GeoJSON MultiPolygon几何对象的运算符表达，可以在$match阶段直接嵌入空间条件。
一、$multiPolygon的数据结构与坐标规则
$multiPolygon接收的是一个数组的数组的数组，也就是三层嵌套。最外层是多个多边形的集合，每个多边形由多个线性环（linear ring）组成，第一个环代表外边界，后续环代表孔洞。每一个坐标点必须是[经度, 纬度]格式，且属于WGS84球面坐标。很多初学者容易把顺序写成纬度在前，这会导致查询区域偏移到错误位置甚至命中全球范围外的空集。
在聚合管道里，我们通常不会手写冗长坐标，而是从已有的区域集合文档中$lookup或者$project提取。但要注意，MongoDB对环的闭合有强制要求：线性环的首尾坐标必须完全一致，否则在解析阶段就会抛出GeoJSON错误。此外，外环必须按逆时针、内环顺时针（或遵循右手定则）才能正确表达带洞区域，虽然部分版本驱动不严格校验，但生产环境建议遵守规范以防索引计算偏差。
下面示例展示了一个包含两个多边形、其中一个带孔洞的$multiPolygon字面量结构：
const multiPoly = {
$multiPolygon: [
[
[
[116.0, 39.0],
[116.5, 39.0],
[116.5, 39.5],
[116.0, 39.5],
[116.0, 39.0]
]
],
[
[
[117.0, 40.0],
[117.8, 40.0],
[117.8, 40.8],
[117.0, 40.8],
[117.0, 40.0]
],
[
[117.2, 40.2],
[117.6, 40.2],
[117.6, 40.6],
[117.2, 40.6],
[117.2, 40.2]
]
]
]
};
二、在聚合管道中组合$multiPolygon与空间运算符
最常用的组合是在$match阶段配合$geoWithin，用来保留那些位置字段落在多多边形内的文档。假设集合orders有loc字段且建立了2dsphere索引，我们可以写如下管道：先匹配时间范围，再用空间条件缩小数据量，这样索引既能用于时间也能用于地理，避免全表扫描。
另一种常见用法是$geoIntersects，它不只关心点是否在内，还处理线、面相交。比如配送路线（LineString）只要和多多边形任一子块有交点就计入。在聚合中，这类空间阶段应尽量前置，因为早期过滤能大幅降低后续$group或$project的计算压力。如果业务还要按子区域拆分统计，可在$addFields中用$function配合 turf.js 逻辑标记所属区块，但这已超出纯MongoDB运算符范畴。
以下代码演示在聚合管道中使用$multiPolygon配合$geoWithin：
db.orders.aggregate([
{ $match: {
createdAt: { $gte: ISODate('2023-01-01') },
loc: {
$geoWithin: {
$geometry: {
type: 'MultiPolygon',
coordinates: [
[[[116.0,39.0],[116.5,39.0],[116.5,39.5],[116.0,39.5],[116.0,39.0]]],
[[[117.0,40.0],[117.8,40.0],[117.8,40.8],[117.0,40.8],[117.0,40.0]],
[[117.2,40.2],[117.6,40.2],[117.6,40.6],[117.2,40.6],[117.2,40.2]]]
]
}
}
}
}},
{ $group: { _id: '$cityCode', total: { $sum: 1 } } }
]);
三、性能特征与常见错误排查
从性能角度看，$multiPolygon查询能否命中2dsphere索引，取决于查询形状是否被MongoDB的地理索引模块识别为有效覆盖。如果坐标未闭合或类型写错成Polygon而非MultiPolygon，会退化为全集合扫描并逐文档计算，这在百万级数据上延迟可达秒级。利用explain('executionStats')观察IXSCAN是否出现是最直接的验证手段。
另一个隐蔽问题是精度与投影。MongoDB默认按球面计算，若误把平面直角坐标当经纬度传入，查询框会缩到极小范围或扩到全球。此外，当多多边形子块过多（如上百个）时，单个查询文档体积变大，网络传输与解析开销上升，此时应考虑按区块分片查询再应用层合并，或借助$bucket按区域预聚合。实践中我们还发现，某些驱动会自动把$multiPolygon坐标拍平一层，导致服务端报坐标维度错误，因此建议在代码里显式构造三层数组。
下面的示例展示如何利用explain检查空间索引使用情况，以及捕获典型坐标错误：
// 检查执行计划
const plan = db.orders.explain('executionStats').aggregate([
{ $match: {
loc: { $geoWithin: {
$geometry: { type: 'MultiPolygon', coordinates: [ [ [ [0,0],[0,1],[1,1],[0,0] ] ] ] }
}}
}}
]);
print(plan.executionStats.executionStages.inputStage.stage);
// 常见错误：环未闭合会抛错
try {
db.orders.aggregate([
{ $match: { loc: { $geoWithin: {
$geometry: { type: 'MultiPolygon', coordinates: [ [ [ [0,0],[0,1],[1,1] ] ] ] }
}}}}
]);
} catch (e) {
print('坐标环未闭合错误: ' + e.message);
}
四、与应用层多多边形处理的对比思考
有些团队选择在后端用Java或Python先判断点是否落在多多边形内，再反查MongoDB。这种做法在区域极复杂、需频繁变更且不愿改索引时可行，但失去了数据库层过滤能力，网络IO和内存占用都偏高。聚合管道内直接使用$multiPolygon能让计算下推到存储节点，特别适合报表类定时任务。
架构上，如果系统已经使用了PostGIS之类专业空间库，MongoDB的$multiPolygon仅适合轻量场景。但当主存储就是MongoDB且查询模式固定，掌握该运算符能省去额外组件维护成本。我们在设计LBS围栏服务时，将运营配置的多边形直接存为MultiPolygon文档，聚合时动态$match引用，整体吞吐量比应用层过滤提升约三倍，同时代码复杂度明显下降。
综上，理解$multiPolygon的结构约束、管道组合方式以及索引行为，是MongoDB地理空间开发的基本功。在真实项目中，配合$geoWithin与$geoIntersects，并养成用explain验证的习惯，才能稳定支撑多区域联合空间分析需求。
MongoDBaggregation_pipeline$multiPolygon修改时间：2026-08-18 22:22:39