写过 SQL 中位数计算的朋友，应该都遇到过 PERCENTILE_CONT 这个函数。它的用法有点讲究：参数必须传 0.5（不是 50，也不是 '0.5'），然后配合 OVER() 或 WITHIN GROUP 使用，返回的是插值结果，而且一定要带上 ORDER BY 排序依据。否则，很容易踩坑。
PERCENTILE_CONT(0.5) 是计算中位数的正确写法
PERCENTILE_CONT 是 SQL 标准里专门算连续分布分位数的函数。中位数对应第 50 百分位，所以参数必须传 0.5——传 50 会报错，传 '0.5' 字符串也可能因类型不匹配导致隐式转换失败。它返回的是插值结果：当行数为偶数时，取中间两个值的平均；奇数时直接取中间那个值。这点和 PERCENTILE_DISC 不同，后者只返回实际存在的某一行值，不做插值。
常见错误是写成 PERCENTILE_CONT(50) 或 PERCENTILE_CONT('0.5')。前者在 PostgreSQL、Oracle 等数据库中会直接报错或返回非预期结果；后者虽然有些数据库能隐式转换，但风险很大，不值得依赖。
必须配合 OVER() 窗口子句使用，不能直接 SELECT
PERCENTILE_CONT 是窗口函数，不能像普通聚合函数那样直接写 SELECT PERCENTILE_CONT(0.5) FROM t。它必须带 OVER()，而且括号里至少要指定排序依据：
OVER (ORDER BY col)：全表按 col 排序后算一个中位数，返回每行相同的值OVER (PARTITION BY group_col ORDER BY col)：按分组分别计算中位数- 千万不能省略
ORDER BY，否则 PostgreSQL 会报错window function requires an ordering clause，SQL Server 也拒绝执行
示例（PostgreSQL）：
SELECT DISTINCT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary) OVER () AS median_salary FROM employees;注意这里的
WITHIN GROUP 语法（PostgreSQL/Oracle 支持）和 OVER(ORDER BY ...) 语义不同。WITHIN GROUP 是聚合式窗口函数，OVER(ORDER BY ...) 是逐行计算的窗口函数，容易混淆，需要区分清楚。
不同数据库对 NULL 和数据类型的处理差异大
NULL 值默认被忽略，但细节上各家有各家的小脾气：
- PostgreSQL：自动过滤 NULL，不影响分位计算，很省心
- SQL Server：同样跳过 NULL，但如果所有值都是 NULL，则返回 NULL
- Oracle：NULL 被排除，但若输入为空集，直接抛出
ORA-30498: percentile value should be between 0 and 1错误——哪怕你传的确实是0.5
数据类型必须支持排序和线性插值。NUMERIC、DECIMAL、FLOAT 这类数值型最安全；INT 会被自动提升为 NUMERIC 再插值；但 VARCHAR 或 DATE 虽然能排序，插值结果却可能没什么意义——比如两个日期中间值是个合法日期，但两个字符串的中间值通常不可用。
替代方案：当 PERCENTILE_CONT 不可用时怎么应急
MySQL 8.0.12+ 才开始支持 PERCENTILE_CONT，旧版本或 SQLite 则完全不支持。这时候就需要手动实现：
- 用
ROW_NUMBER()+COUNT()算出中间位置，再用条件聚合取值（偶数时取上下两行平均） - 避免用
LIMIT/OFFSET分页取中间行，因为无法处理偶数情况，而且性能差 - 如果只是单次查中位数，数据量不大时，用应用层排序更可控
关键点在于：数据库原生 PERCENTILE_CONT 的插值逻辑是确定的，手动实现时必须严格复现“偶数时均值、奇数时中值”的规则，否则和业务预期不符。
真正麻烦的是跨数据库兼容性——同一个 SQL 在 PostgreSQL 跑得通，在 SQL Server 可能因 WITHIN GROUP 不支持而失败。这时候得根据目标方言切换写法，别指望一次写完到处跑。
