PERCENTILE_CONT是连续插值型百分位函数，返回理论中位数；PERCENTILE_DISC是离散型，返回数据集中实际存在的最接近值。二者核心区别在于：前者线性插值（如[1,3,5,7]得4.0），后者取排序后位置值（同例得3），且均需WITHIN GROUP(ORDER BY ...)语法。
PERCENTILE_CONT 是什么函数，它和 PERCENTILE_DISC 有什么区别
PERCENTILE_CONT 是标准 SQL（PostgreSQL、Oracle、SQL Server、Snowflake 等支持）中用于计算连续分布下的百分位数的聚合函数。它会基于线性插值返回一个理论上的中间值，而不是从原始数据中挑一个现成的值。
PERCENTILE_DISC 则直接返回数据集中「等于或大于指定百分位」的最小实际值，结果一定来自原数据 —— 所以它是离散的、不插值的。
常见错误现象：在 PostgreSQL 中写 PERCENTILE_CONT(0.5) 却没加 WITHIN GROUP (ORDER BY ...)，报错 function percentile_cont(double precision) does not exist —— 这是因为它必须明确排序依据，不能像普通聚合那样隐式处理。
使用场景：
- 需要平滑统计中位数（比如用户响应时长的“理论中位”而非某个具体请求耗时）
- 报表要求符合 ISO/IEC 33001 等标准中对连续百分位的定义
- 和 BI 工具（如 Tableau、Looker）对接时需保持一致插值逻辑
注意：PERCENTILE_CONT 必须配合 WITHIN GROUP (ORDER BY column) 使用，且该列不能为 NULL（NULL 会被自动忽略，但若全为 NULL 则返回 NULL）。
怎么写正确的 PERCENTILE_CONT 语法（含常见数据库差异）
不同数据库对 PERCENTILE_CONT 的参数和窗口支持略有不同，核心差异在是否允许作为窗口函数使用：
- PostgreSQL：只支持聚合形式（即必须带
GROUP BY或全表聚合），不支持窗口用法 - SQL Server：支持聚合和窗口两种形式，但窗口版需搭配
OVER (ORDER BY ...) - Snowflake / Oracle：两者都支持，且窗口版可带
PARTITION BY
实操建议：
- 如果你只想算整个表的中位数，统一用聚合写法最稳妥：
SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY response_time_ms) AS median_time FROM requests;
- 如果想按用户分组算各自 P90 响应时间，在 PostgreSQL 中必须写成：
SELECT user_id, PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY response_time_ms) AS p90_time FROM requests GROUP BY user_id; - 在 SQL Server 或 Snowflake 中，你也可以用窗口函数避免 GROUP BY：
SELECT user_id, response_time_ms, PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY response_time_ms) OVER (PARTITION BY user_id) AS p90_per_user FROM requests;
性能影响：由于需要排序 + 插值计算，PERCENTILE_CONT 比 AVG 或 COUNT 开销大得多；大数据量时建议在 ORDER BY 列上建索引（如 CREATE INDEX idx_req_time ON requests(response_time_ms)）。
为什么结果是 NULL？几个容易踩的坑
PERCENTILE_CONT 返回 NULL 并不总是代表出错，但常被误判。真实原因包括：
- 输入列全为
NULL：函数跳过所有 NULL 后无有效值可插值，返回 NULL - 参数超出范围：传入
PERCENTILE_CONT(-0.1)或PERCENTILE_CONT(1.5)，多数数据库会报错（如 PostgreSQL 报percentile value must be between 0 and 1），但有些（如旧版 SQL Server）可能静默转为边界值 - 数据类型不匹配：传入字符串列（如
ORDER BY status）会导致排序无效，插值失败 —— 必须是数值型或可自然排序的类型（日期也 OK） - 在窗口函数中未正确控制窗口帧：例如写成
OVER (ORDER BY ts ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)，会导致每行只看到部分数据，插值结果不可靠；连续百分位一般应使用ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING或干脆省略（默认全窗口）
调试技巧：先用 COUNT(*) 和 COUNT(column) 对比，确认非空值数量；再用 MIN(column), MAX(column) 看值域是否合理 —— 如果只有 1 条非空记录，PERCENTILE_CONT(0.5) 就等于它自己，但 PERCENTILE_CONT(0.9) 可能因插值外推而异常（取决于实现）。
替代方案：没有 PERCENTILE_CONT 怎么办（如 MySQL 8.0 以前）
MySQL 直到 8.0.11 才支持 PERCENTILE_CONT，早期版本只能手写近似逻辑：
-
方案一：用变量模拟排序后取第 N 行（适合中小数据量）
SELECT AVG(val) AS p50 FROM ( SELECT val, @row := @row + 1 AS row_num, @count AS total_count FROM t, (SELECT @row := 0, @count := COUNT(*) FROM t) r ORDER BY val ) ranked WHERE row_num IN (FLOOR((total_count + 1) / 2), CEIL((total_count + 1) / 2)); 方案二：用
LIMIT+ 偏移（仅适用于中位数，且无法插值）方案三：导出到 Python/Pandas 用
np.percentile(..., method='linear')计算后再回写
关键点：这些替代方法都不等价于标准 PERCENTILE_CONT —— 它们要么不插值，要么插值方式不同（比如 Pandas 默认用 ‘linear’，但某些数据库用 ‘averaged’ 或 ‘hazen’）。如果报表审计要求严格，最好升级数据库或换用支持标准函数的引擎。
真正麻烦的是跨数据库迁移时，同一个 PERCENTILE_CONT(0.95) 在 PostgreSQL 和 SQL Server 上结果可能差零点几个毫秒——不是 bug，是插值算法细节不同。别只看文档说“都支持”，得实测验证。
