PERCENTILE_CONT(0.5) 是窗口函数，必须配合 OVER() 或 WITHIN GROUP 使用，不可直接聚合；不同数据库语法和 NULL 处理逻辑不同，需显式过滤 NULL 并确保 ORDER BY 字段为数值型且有索引。
PERCENTILE_CONT(0.5) 是计算中位数最直接的方式，但必须配合 OVER() 才能生效
很多人写 PERCENTILE_CONT(0.5) 直接报错，比如 ERROR: function percentile_cont(double precision) does not exist 或返回空值，根本原因是它是个窗口函数，不能当普通聚合函数用。你不能写 SELECT PERCENTILE_CONT(0.5) FROM sales —— 这语法不合法。
正确姿势是绑定 OVER()，哪怕你不需要分区或排序，也得写成 PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY amount)（PostgreSQL/SQL Server）或 PERCENTILE_CONT(0.5) OVER (ORDER BY amount)（某些引擎如 BigQuery）。注意：两种语法不能混用。
- PostgreSQL 和 SQL Server 支持
WITHIN GROUP语法，此时它行为类似聚合函数，可搭配GROUP BY - BigQuery、Snowflake 默认只认
OVER()窗口写法，且要求ORDER BY子句不可省略 - MySQL 不支持
PERCENTILE_CONT，别白费劲；得用变量或ROW_NUMBER()模拟
ORDER BY 字段必须是数值型，且 NULL 值会影响结果位置
PERCENTILE_CONT 内部按指定字段升序排序后插值，如果 ORDER BY 的列含大量 NULL，不同数据库处理方式不同：PostgreSQL 默认把 NULL 排在最前，而 SQL Server 把它排最后。这会导致中位数算出来差一两个值。
实操建议：
- 显式过滤掉
NULL：WHERE amount IS NOT NULL，比依赖默认排序更可靠 - 避免用字符串字段排序，比如
ORDER BY customer_id::text—— 即使customer_id是数字，转字符串后排序就变成字典序，中位数毫无意义 - 如果业务允许，提前用
COALESCE(amount, 0)填充，但要清楚 0 是否代表真实业务含义
和 PERCENTILE_DISC(0.5) 的区别不是“精确 vs 近似”，而是“插值 vs 取现有值”
看到文档说 PERCENTILE_CONT 返回连续分布的插值结果，PERCENTILE_DISC 返回离散分布的现有值，容易误解为前者更“准”。其实关键差异在于：当样本数为偶数时，PERCENTILE_CONT(0.5) 会取中间两数的平均值（比如 [1,2,3,4] → 2.5），而 PERCENTILE_DISC(0.5) 只返回靠前的那个（→ 2）。
选哪个取决于业务定义：
- 财务类指标（如客单价中位数）通常接受插值，用
PERCENTILE_CONT - 用户等级、评分等只能取整的场景（如“一半用户等级 ≤ X”），用
PERCENTILE_DISC更符合语义 - 两者在奇数行时结果一致，但别因此忽略它们底层逻辑差异
大数据量下性能容易被低估，ORDER BY 成为瓶颈
PERCENTILE_CONT 必须对整个输入集排序，不像 COUNT 或 SUM 能流式计算。当表有千万级记录且没走索引时，执行计划里常出现 Sort 节点占 70%+ 时间。
提速手段有限但有效：
- 确保
ORDER BY字段上有索引，例如CREATE INDEX idx_sales_amount ON sales(amount) - 先用
WHERE缩小范围再算中位数，而不是全表扫完再过滤 - 如果只是近似中位数够用，考虑用
APPROX_QUANTILES（BigQuery）或采样 +PERCENTILE_CONT，误差可控且快一个数量级
中位数看着简单，但数据库实现上它本质是一次强制全局排序 —— 这点在写报表 SQL 时最容易被忽略。
