PERCENTILE_CONT是SQL标准中基于线性插值计算连续型百分位数的聚合/窗口函数，返回理论值；PERCENTILE_DISC则返回数据集中实际存在的离散值。二者均需WITHIN GROUP(ORDER BY ...)语法，但CONT结果可能不在原数据中（如[1,3,5,7]得4.0），DISC结果必为原数据之一（同例得3）。
PERCENTILE_CONT 是什么，它和 PERCENTILE_DISC 有什么区别
PERCENTILE_CONT 是 SQL 标准中用于计算连续型百分位数的窗口函数，它会基于线性插值返回一个理论上的中间值，而不是从现有数据中挑一个。比如你查第 50 百分位（中位数），如果数据行数是偶数，它不会简单取中间两行的任意一个，而是做平均；如果是奇数，也不直接取中间那行，而是仍按插值逻辑算——结果往往和 MEDIAN() 函数一致（在支持它的数据库里）。
PERCENTILE_DISC 则相反：它只返回实际存在的某个观测值，不做插值，结果一定是输入列里的某个原始值。
常见错误现象：PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY x) 在 PostgreSQL 中能用，在 MySQL 8.0+ 不支持（会报 FUNCTION xxx.PERCENTILE_CONT does not exist），而 Oracle 和 SQL Server 的语法位置略有不同（SQL Server 要求必须配合 OVER() 窗口定义，不能用 WITHIN GROUP）。
使用场景：需要平滑统计指标（如响应时间 P95、P99）、报表中避免“跳变”、或与监控系统对齐时，优先选 PERCENTILE_CONT；若必须保证结果可追溯到某条真实记录（如审计场景），才考虑 PERCENTILE_DISC。
PostgreSQL 中怎么写 PERCENTILE_CONT 的基本语法
PostgreSQL 支持两种调用方式，但行为不同：
-
作为聚合函数（单值输出）：
SELECT PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY response_time_ms) FROM requests;
-
作为窗口函数（每行都算一个百分位参考值）：
SELECT user_id, response_time_ms, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY response_time_ms) OVER () AS p95_global FROM requests;
注意点：
-
PERCENTILE_CONT必须跟WITHIN GROUP (ORDER BY ...)，不能省略 - 排序字段必须是数值类型，否则报错
cannot order by type text - 如果
response_time_ms有NULL，默认会被忽略（不影响插值范围），但如果你显式想排除，得先WHERE response_time_ms IS NOT NULL - 参数必须是 0 到 1 之间的
double precision常量或参数化变量（不能是子查询或表达式）
SQL Server 和 Oracle 的关键差异点
SQL Server 要求强制使用窗口语法，不支持 WITHIN GROUP：
SELECT DISTINCT
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY response_time_ms)
OVER () AS p95
FROM requests;⚠️ 实际上这是错的——SQL Server 根本不认 WITHIN GROUP。正确写法是：
SELECT TOP 1
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY response_time_ms)
OVER (ORDER BY response_time_ms ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS p95
FROM requests;更稳妥的写法（推荐）：
SELECT PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY response_time_ms)
OVER () AS p95
FROM (SELECT TOP 1 1 AS dummy) t;Oracle 更接近 PostgreSQL，但要求 ORDER BY 字段不能是表达式（比如 ORDER BY ABS(x) 会报错 ORA-30498: expression must be a constant or column reference）。
性能影响：
- 所有数据库都会对指定字段做隐式排序，大数据量下可能触发磁盘排序（
tempdb或PG_TEMP） - 在 SQL Server 中，如果没建索引，
PERCENTILE_CONT可能比等价的OFFSET/FETCH手动实现慢 3–5 倍
为什么有时结果是 NULL，怎么排查
最常见原因不是数据为空，而是：
- 输入列全为
NULL（此时返回NULL，不是报错） -
PERCENTILE_CONT的参数超出范围：小于 0 或大于 1（PostgreSQL 报ERROR: percentile value must be between 0 and 1，SQL Server 直接失败） - 在窗口函数中用了错误的
OVER子句，比如OVER (PARTITION BY user_id ORDER BY ts)但某个user_id分组下只有一行——这时仍能算，但插值无意义；若该分组为空，则对应行结果为NULL
调试建议：
- 先确认基础分布：
SELECT COUNT(*), COUNT(response_time_ms) FROM requests; - 检查极值：
SELECT MIN(response_time_ms), MAX(response_time_ms) FROM requests WHERE response_time_ms IS NOT NULL; - 临时改用
PERCENTILE_DISC对照看是否也 NULL，排除数据本身问题
真正容易被忽略的是：不同数据库对空值的处理策略不一致，且 PERCENTILE_CONT 在窗口模式下，ORDER BY 子句里如果有重复值，插值逻辑可能因排序稳定性产生微小偏差——这不是 bug，是定义使然。
