percentile_cont 性能差主因是必须全量排序插值，无法流式计算或复用索引；替代方案包括 ntile 近似、percentile_disc 省插值、预计算物化视图。
因为 PERCENTILE_CONT 在多数数据库中必须对输入数据**全量排序后插值**，而排序是 O(n log n) 操作——数据量翻倍，耗时往往翻两倍以上。它不像 AVG 或 COUNT 那样能流式计算，也不能靠索引跳过排序阶段。
为什么不能直接用索引加速？
即使你在排序字段（如 amount）上建了 B-tree 索引，PERCENTILE_CONT 仍大概率无法受益：
- PostgreSQL 的
WITHIN GROUP (ORDER BY ...)聚合会触发一次独立的内部排序，不复用已有索引；只有在配合GROUP BY且数据已按分组+排序字段物理聚簇时，才可能减少排序开销 - SQL Server 完全不支持
WITHIN GROUP，只能走OVER (ORDER BY ...)窗口函数路径，每次调用都强制重排，且无法与索引 hint 绑定 - 索引仅加速“定位”，而百分位数需要“确定第 k 个位置的值”，本质依赖有序序列的全局位置，不是点查
常见写法如何让性能雪上加霜？
这些看似合理、实则高危的操作会显著放大延迟：
- 在
ORDER BY子句里用表达式：比如PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY ABS(amount))—— PostgreSQL 会拒绝使用索引，强制计算后再排序 - 未过滤 NULL：虽然 NULL 默认被忽略，但引擎仍需逐行判断，大数据集下 I/O 和 CPU 开销明显；更糟的是，某些版本（如旧版 SQL Server）会对 NULL 做特殊排序处理，拖慢整体流程
- 一次请求多个百分位：例如
PERCENTILE_CONT(ARRAY[0.1,0.5,0.9])（Databricks）或用generate_series循环调用（PostgreSQL）——等于做多次完整排序
有没有真正快一点的替代方案？
有，但得接受精度或语义上的微小妥协：
- 用
NTILE(100) OVER (ORDER BY amount)+ 分组取最大值：单次扫描完成，适合 P1–P100 连续需求，但结果是离散桶边界，不是数学精确值 - 改用
PERCENTILE_DISC：底层逻辑相同（仍要排序），但省去插值计算，在超大数据集上可节省 5–15% 时间；尤其当业务只要“真实存在的中位数”时，它更轻量 - 预计算并落库：对变化不频繁的指标（如每日用户消费分布），用物化视图或定时任务把
NTILE结果存成汇总表，查询直接走索引
最易被忽略的一点：PERCENTILE_CONT 的慢，往往不是函数本身的问题，而是你让它在没准备好的数据上硬算——比如没建索引、没分区裁剪、没提前过滤掉测试脏数据。它不像 SUM 那样宽容，对输入质量极度敏感。
