PERCENTILE_CONT 返回 NULL 的最常见原因是输入列全为 NULL 或分组后无有效数据；其严格遵循 SQL 标准，不自动忽略 NULL，需显式过滤（如 WHERE col IS NOT NULL）或使用 FILTER 子句。
PERCENTILE_CONT 为什么返回 NULL 而不是数值
最常见的现象是执行 PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY col) 却得到 NULL。根本原因只有两个：输入列全为 NULL，或 GROUP BY 后某组无有效数据。PostgreSQL 不会跳过 NULL 值再计算——它直接按标准 SQL 规则把整组视为无效。确认方法很简单：先跑 SELECT COUNT(*), COUNT(col) FROM tbl，如果两者不等，说明有 NULL 干扰。
实操建议：
- 务必在
ORDER BY子句里用col IS NOT NULL过滤，例如：PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY col) FILTER (WHERE col IS NOT NULL) - 若源表 NULL 多，更稳妥的是提前清洗：
WHERE col IS NOT NULL写在主查询 WHERE 条件里 - 窗口函数场景下，
PARTITION BY分组中某分区若无非 NULL 值，对应行结果必为NULL，无法避免
连续分位数 vs 离散分位数：PERCENTILE_CONT 和 PERCENTILE_DISC 的区别
PERCENTILE_CONT 做线性插值，结果可能是小数（哪怕原始数据全是整数）；PERCENTILE_DISC 只返回实际存在的值，取排序后最接近该分位位置的那一个。比如 1,2,3,4 四个数求中位数：PERCENTILE_CONT(0.5) 返回 2.5，PERCENTILE_DISC(0.5) 返回 2。
选择依据很实际：
- 需要统计报表里“理论中间值”（如响应时间 P50），用
PERCENTILE_CONT - 要查“真实发生过的第 50% 阈值”，比如“至少一半用户订单金额 ≤ X”，用
PERCENTILE_DISC -
PERCENTILE_CONT计算开销略高，尤其大数据集上插值逻辑涉及浮点运算和边界判断
在 GROUP BY 或窗口函数中正确使用 PERCENTILE_CONT
语法上必须带 WITHIN GROUP (ORDER BY ...)，且括号内只能是单列、不能含表达式或函数调用（如 ORDER BY abs(x) 会报错 ERROR: ORDER BY in percentile_cont must be a simple column reference）。常见错误是把它当普通聚合函数混用。
正确写法示例：
SELECT dept, PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY salary) AS p90_salary FROM employees GROUP BY dept;
窗口函数写法（注意：不能同时写 OVER() 和 WITHIN GROUP）：
SELECT
name,
salary,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary)
OVER (PARTITION BY dept) AS dept_median
FROM employees;
关键限制：
- 不支持
DISTINCT修饰，去重需提前用子查询或 CTE - 排序列类型必须支持 B-tree 比较（多数数值、日期、字符串都行，但 JSON 类型不行）
- 传入
0.0或1.0是合法的，分别等价于MIN()和MAX()，但性能不如直接用后者
精度陷阱：浮点误差与数据类型隐式转换
当输入列为 NUMERIC 但精度很高（如 NUMERIC(18,12)），PERCENTILE_CONT 插值结果可能因内部 float8 计算丢失末位精度。这不是 bug，而是 PostgreSQL 明确文档写的“interpolation uses double precision arithmetic”。例如对 1.000000000001 和 1.000000000003 求 P50，结果可能是 1.0000000000019998 而非精确的 1.000000000002。
应对方式取决于需求：
- 展示层四舍五入即可：
ROUND(..., 12) - 要求严格精度时，改用
PERCENTILE_DISC+ 手动实现插值逻辑（复杂，仅必要时） - 避免在
ORDER BY列上用CAST强转类型，比如ORDER BY CAST(x AS FLOAT8)会触发隐式转换失败
真正容易被忽略的是：同一个查询里混合使用不同小数位数的 NUMERIC 列做分位计算时，PostgreSQL 会统一提升精度，可能导致内存占用突增，尤其在大表窗口函数中。先用 pg_column_size() 测一下典型值大小更稳妥。
