MongoDB聚合管道无原生$percentile操作符，需用$sort+$group+$arrayElemAt模拟中位数：先排序聚合成数组，再按奇偶长度取中间值或平均；P95等百分位数需动态算索引并防越界；大数据量易内存溢出，分片集群下性能差，生产环境推荐预计算或应用层处理。
聚合管道里没有直接的 $percentile 操作符
MongoDB 原生聚合阶段（截至 7.0）不提供类似 SQL 的 PERCENTILE_CONT 或内置中位数函数。强行用 $group + $avg 算“平均值”不是中位数，用 $min/$max 更是完全跑偏。真实需求下必须靠排序 + 数组切片模拟——核心思路是：先排序取全量数组，再按索引取值。
用 $sort + $group + $arrayElemAt 手动算中位数
中位数本质是有序数组中间位置的值（奇数长度取正中，偶数取中间两数平均）。关键在于把字段值聚合成有序数组，再定位索引：
[
{ $sort: { "score": 1 } },
{ $group: { _id: null, scores: { $push: "$score" } } },
{
$project: {
median: {
$cond: {
if: { $eq: [{ $mod: [{ $size: "$scores" }, 2] }, 1] },
then: { $arrayElemAt: ["$scores", { $floor: { $divide: [{ $size: "$scores" }, 2] } }] },
else: {
$divide: [
{ $add: [
{ $arrayElemAt: ["$scores", { $subtract: [{ $divide: [{ $size: "$scores" }, 2] }, 1] }] },
{ $arrayElemAt: ["$scores", { $divide: [{ $size: "$scores" }, 2] }] }
]
},
2
]
}
}
}
}
}
]- 必须先
$sort，否则$push顺序无保证；$push在$group阶段才生成有序数组 -
$arrayElemAt索引从 0 开始，偶数长度时中间两索引是n/2 - 1和n/2（例如长度 4 → 索引 1 和 2） - 该方法在数据量大时内存压力明显：
$push会加载全部匹配文档的字段值到内存，集合超 10 万条易触发errmsg: "Sort exceeded memory limit"
计算任意百分位数（如 P95）要动态算索引位置
百分位数 = 排序后第 floor((p/100) * (n-1)) 个元素（线性插值法更准，但 MongoDB 不支持浮点索引，常用向下取整+边界检查）：
{
$project: {
p95: {
$arrayElemAt: [
"$scores",
{ $floor: { $multiply: [{ $size: "$scores" }, 0.95] } }
]
}
}
}- 注意：MongoDB 数组索引最大为
size - 1，所以$multiply结果需用$min截断，避免越界（例如{ $min: [{ $floor: ... }, { $subtract: [{ $size: "$scores" }, 1] }] }） - 若要求插值（如 P95 位于索引 94.5 处），得用
$let提取前后两个值再加权，但逻辑复杂且无法规避精度损失 - 分片集群下该聚合无法下推到 shard，所有数据会汇总到 primary shard 再计算，延迟和失败风险上升
生产环境更推荐预计算或应用层处理
实时聚合算百分位数在大多数业务场景属于高成本低频操作。真要高频使用，优先考虑：
- 写入时用 TTL 集合定期跑后台任务，用
db.collection.aggregate(...)结果存入统计表，查时直取 - 导出数据到 Spark / Python（
numpy.percentile或pandas.Series.quantile），尤其当需要多维分组+多个分位点时，代码可读性和性能远超聚合表达式 - 升级到 MongoDB 7.0+ 后留意
$percentile（目前仅限 Atlas Search 聚合，非通用聚合管道）——别信旧教程里“已支持”的说法，官方文档明确标注为实验性且受限
数组索引越界、内存溢出、分片数据倾斜——这几个坑在测试小数据时完全不暴露，一上生产就卡死。动手前先 db.collection.count() 看量级，比硬写聚合更重要。
