无PERCENTILE_CONT时，须用ROW_NUMBER()配合COUNT()手动计算中位数：先按组排序编号，再根据奇偶性取第(n+1)/2行或n/2与n/2+1行平均值，并注意过滤NULL、避免RANK()干扰。
SQL里没有PERCENTILE_CONT但又要算中位数怎么办
很多旧版数据库（比如MySQL 5.7、早期PostgreSQL）不支持PERCENTILE_CONT，但业务上又常需要分组后取中位数、90分位这类值。这时候得靠窗口函数+排序+行号硬算，核心思路是：先按组排序并编号，再根据总行数定位目标位置。
常见错误是直接用ROUND(COUNT(*) * 0.5)当索引去查，结果在偶数行时拿不到两个中间值的平均——它只返回一个值，且没处理NULL或重复值干扰。
- 必须用
ROW_NUMBER()而非RANK()，避免相同值挤占位置导致索引偏移 - 对每个分组单独计算
COUNT(*)，不能跨组复用 - 中位数要兼容奇偶：奇数取第
(n+1)/2行，偶数取第n/2和n/2+1行的平均 - 示例（PostgreSQL兼容写法）：
SELECT group_id, AVG(val) AS median FROM ( SELECT group_id, val, ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY val) AS rn, COUNT(*) OVER (PARTITION BY group_id) AS cnt FROM data_table ) t WHERE rn IN (FLOOR((cnt + 1) / 2.0), CEIL((cnt + 1) / 2.0)) GROUP BY group_id;
MySQL 8.0+用PERCENTILE_CONT为什么结果还是不对
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY val)看着简洁，但实际踩坑点不少：它默认忽略NULL，如果分组内val全是NULL，整组就消失；而且它要求ORDER BY字段类型严格可比，比如混合了字符串和数字会报错Invalid type for ORDER BY。
- 务必提前
WHERE val IS NOT NULL过滤，否则分组可能被静默丢弃 - 确认
val字段类型统一，必要时加CAST(val AS DECIMAL) - 百分位参数必须在0到1之间，传
1.0会报错，0.0返回最小值（不是MIN()，而是排序后第一个非NULL值） - 性能敏感场景慎用：它内部做完整排序，大数据量分组下比手动
ROW_NUMBER()慢2–3倍
分组后算95分位但数据倾斜严重怎么稳住精度
当某组数据量极大（比如百万级）、且分布极不均匀（大量重复值集中在头部），PERCENTILE_CONT(0.95)容易卡在重复值边界，返回值未必是真实第95%位置的数——因为窗口函数只保证“插值连续”，不保证“离散精确”。
这时得切回手动法，但要改策略：不用行号硬匹配，改用累计占比。
- 用
SUM(COUNT(*)) OVER (PARTITION BY group_id ORDER BY val ROWS UNBOUNDED PRECEDING)算累计频次 - 再除以该组总数，得到每个
val对应的“小于等于它的比例” - 找第一个累计比例≥0.95的
val，就是离散95分位点 - 注意：这个方法天然抗重复值干扰，但无法插值（比如0.95刚好卡在两个值之间时，它取大的那个）
不同数据库对NULL和空组的处理差异
同一个SQL在PostgreSQL、SQL Server、Oracle跑，结果可能不一样：PostgreSQL的PERCENTILE_CONT遇到空组直接返回NULL；SQL Server则抛错Argument data type numeric is invalid for argument 1 of percentile_cont function；而MySQL 8.0对空组返回NULL但不报错。
- 写通用SQL前，先查目标库文档确认
PERCENTILE_CONT是否支持空组、是否允许NULL参与排序 - 生产环境建议统一加
HAVING COUNT(*) > 0过滤空组，避免行为不一致 - 如果必须兼容多库，放弃内置函数，用
ROW_NUMBER()方案更可控——虽然啰嗦，但逻辑透明
实际用的时候，别光看函数名是不是写着“percentile”，重点盯三点：它怎么处理NULL、空组返回什么、以及95分位这种边界值到底是插值还是取离散点。这几个细节一错，报表数值就偏了。
