PERCENTILE_CONT 返回 NULL 主因是未正确指定 ORDER BY 或排序列含 NULL；必须用 WITHIN GROUP (ORDER BY col)，且需确保排序字段类型一致、无 NULL 值。
PERCENTILE_CONT 算出来总是 NULL？检查 ORDER BY 和数据类型
用 PERCENTILE_CONT 算分组中位数，结果全为 NULL，大概率是没写对 ORDER BY 子句，或者排序字段含 NULL 值。这个函数要求显式指定排序依据，且不跳过 NULL——只要排序列里有一个 NULL，整组结果就可能失效。
-
PERCENTILE_CONT(0.5)必须跟WITHIN GROUP (ORDER BY col)，漏掉括号或写成OVER (ORDER BY col)都会报错或返回空 - 排序字段如果是字符串或浮点数，要注意隐式转换：比如
score VARCHAR存着'95'和'100'，按字典序排就是'100' ，中位数就错了 - postgresql 和 oracle 支持该函数；mysql 8.0+ 不支持
PERCENTILE_CONT，得用PERCENT_RANK()+ 自联查模拟
窗口函数里套 PERCENTILE_CONT 报错 “window function not allowed here”
想在 select 里一边取分组均值、一边算中位数，直接写 PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY x) OVER (PARTITION BY y) 会报错——PERCENTILE_CONT 是聚合函数，不是窗口函数，不能加 OVER。它只能配合 GROUP BY 使用。
- 正确姿势是：先用
GROUP BY做聚合，再把中位数作为一列参与后续计算；如果真要“每行都带本组中位数”，得用子查询或 CTE 拉平 - 例如：先
SELECT dept, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary) AS med_salary FROM emp GROUP BY dept，再和原表JOIN - 别试图用
ROW_NUMBER()手动找中间行来替代——当组内行数为偶数时，得平均两个中间值，自己实现容易漏掉边界逻辑
不同数据库对 PERCENTILE_CONT 的插值规则不一致
PERCENTILE_CONT(0.5) 理论上应返回线性插值结果，但实际行为要看数据库实现。PostgreSQL 严格按连续分布插值；SQL Server 在某些版本里会退化为 PERCENTILE_DISC 行为（取实际存在的值），Oracle 则默认按标准定义处理。
- 测试时用小数据集验证：比如
[1, 3]组，中位数应为2.0，不是1或3；若得到整数，说明可能被当成离散模式了 - SQL Server 中需确认是否启用了兼容级别 110+，低版本可能忽略
CONT后缀语义 - 避免跨库迁移时硬编码依赖插值结果，尤其涉及财务或统计报告场景——宁可显式用
(MIN + MAX) / 2或MEDIAN()（如 DuckDB）等更透明的方式
大数据量下 PERCENTILE_CONT 性能骤降，怎么缓一缓
百万级表上对高基数分组（比如按用户 ID 分组算每次点击时长中位数）跑 PERCENTILE_CONT，很容易卡住或 OOM。它内部需要对每组数据排序并插值，不是简单扫描能搞定的。
- 优先考虑加索引：
CREATE INDEX ON t (group_col, value_col)，让排序走索引扫描 - 如果精度允许，用近似中位数函数替代：PostgreSQL 可用
approx_percentile(0.5, value_col)（需安装tdigest扩展），BigQuery 用APPROX_QUANTILES(value, 100)[OFFSET(50)] - 别在
WHERE条件没过滤前就调用它——先WHERE status = 'done'再聚合，比在全量上算完再HAVING筛选快得多
实际用的时候，最常翻车的是把 WITHIN GROUP 当成可有可无的装饰，或者以为它能像 SUM() 那样自然融入窗口逻辑。它本质是个带排序要求的聚合，得按聚合的规矩来。