PERCENTILE_CONT 返回单个值是因为未配合 GROUP BY 分组，导致整表被当作一个组计算全局百分位数；正确用法需显式分组并包含分组字段，且必须使用 WITHIN GROUP (ORDER BY ...) 语法指定排序，该函数通过线性插值返回连续分布下的理论值而非原始数据中的实际值。
percentile_cont 为什么返回单个值而不是每组中位数
直接对分组数据用 percentile_cont(0.5) 却只得到一行结果？这是因它默认是窗口函数行为，但作为聚合函数使用时，必须配合 GROUP BY —— 而且不能漏掉分组字段。否则 PostgreSQL 会把整张表当一组处理。
常见错误写法：SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY score) FROM students; → 只返回一个全局中位数。
正确做法是显式分组：
SELECT class, percentile_cont(0.5) WITHIN GROUP (ORDER BY score) AS median_score FROM students GROUP BY class;
-
WITHIN GROUP (ORDER BY ...)是强制语法，不可省略，且括号内不能有别名或表达式（如score * 1.0需提前在子查询里算好） - 如果
class为NULL，该行会被归入同一组；需要排除就加WHERE class IS NOT NULL -
percentile_cont返回的是连续插值结果（比如 [1,2,3,4] 的中位数是 2.5），若要离散中位数（取中间靠左/右的原始值），得换percentile_disc
处理空值和数据类型不匹配的报错
执行时报错 ERROR: input of anonymous composite type is not supported 或 cannot cast type text to double precision？大概率是 ORDER BY 字段存在 NULL 或类型混杂。
percentile_cont 要求排序字段必须是可比较的数值或时间类型，且 NULL 默认被排在最前（影响插值位置）。建议提前清理：
- 用
WHERE score IS NOT NULL过滤，避免NULL干扰排序位置计算 - 若字段是
text存数字（如'12.5'），必须显式转类型：ORDER BY score::numeric，否则会按字符串排序（'100' ） - 混合类型如
int和float通常自动转为double precision，但含money或自定义域类型时需手动转为numeric
和 percentile_disc 的关键区别在哪
用 percentile_cont(0.5) 得到 4.7，但业务要求“取实际存在的中间值”（比如 [1,3,5,7] 必须返回 3 或 5）？那就该换 percentile_disc。
两者核心差异：
-
percentile_cont：线性插值，结果可能是原始数据里不存在的值；要求输入类型支持连续域（如numeric,timestamp） -
percentile_disc：返回排序后位置最接近的**现有值**（向下取整索引），结果必来自原始列；支持更多类型（包括text，按字典序） - 偶数个值时：
percentile_cont(0.5)插值得到平均值，percentile_disc(0.5)直接取第n/2个（即靠左的中间值）
例如数据 [10, 20, 30, 40]：percentile_cont(0.5) → 25.0percentile_disc(0.5) → 20
性能差得明显？注意排序开销和索引失效
百万级表上跑 GROUP BY + percentile_cont 慢得像卡住？根本原因是 WITHIN GROUP (ORDER BY ...) 无法利用普通 B-tree 索引——它需要对每组数据单独排序，而 PostgreSQL 不支持“按 group 排序”的预建索引。
优化方向很有限，但可减少伤害：
- 确保分组字段（如
class）有索引，加速分组扫描 - 若只查少数几个组，用
WHERE class IN ('A', 'B')提前过滤，避免全表分组 - 避免在
ORDER BY里用函数（如ORDER BY abs(score)），这会让排序彻底无法走索引 - 真有高频中位数需求，考虑物化视图定期预计算，或改用近似算法（如
tdigest扩展）
真正容易被忽略的是：即使加了 score 索引，percentile_cont 也不会用它做排序加速——它内部就是 sort + scan，和 ORDER BY 查询走索引不是一回事。
