PERCENTILE_CONT 是基于连续分布模型、通过线性插值计算指定百分位数的聚合函数；它返回精确中位数（如 PERCENTILE_CONT(0.5)），而 AVG 计算平均值易受异常值干扰，标准 SQL 无 MEDIAN 函数且 PERCENTILE_DISC 返回离散值不平滑。
PERCENTILE_CONT 是什么，为什么不能直接用 AVG 或 MEDIAN
PERCENTILE_CONT 是 PostgreSQL 提供的连续分布分位数计算函数，它通过线性插值返回指定百分位的值；而标准 SQL 没有内置 MEDIAN 函数，AVG 算的是平均数，对偏态数据完全失真。比如销售额字段存在大量 0 和个别百万级异常值时，AVG 可能是 5 万，但真实中位数可能只有 800 —— 这时候必须用 PERCENTILE_CONT。
常见错误现象：SELECT MEDIAN(sales) FROM orders 直接报错 ERROR: function median(numeric) does not exist；或者误用 PERCENTILE_DISC 导致结果跳变（它取实际存在的离散值，非平滑中位）。
-
PERCENTILE_CONT(0.5)才是严格意义的中位数，且支持小数插值（如第 3 和第 4 个数之间取中间值） - 必须搭配
WITHIN GROUP (ORDER BY ...)子句，不支持普通 WHERE 后直接跟 - 输入表达式类型需为数值或可排序类型（如
timestamp），text类型会报cannot order text without collation
如何正确写一个带 GROUP BY 的中位数查询
业务场景很常见：查每个城市订单金额的中位数，而不是全表一个值。这时候不能把 PERCENTILE_CONT 放在 SELECT 顶层再 GROUP BY，必须用窗口或子查询结构。
正确写法是把分位计算放在聚合层，和 AVG、COUNT 并列：
SELECT city, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY amount) AS median_amount, COUNT(*) AS order_count FROM orders GROUP BY city;
容易踩的坑：
- 漏写
WITHIN GROUP (ORDER BY ...)→ 报错ERROR: missing WITHIN GROUP clause - ORDER BY 字段含 NULL：默认 NULLS LAST，若想把 NULL 当最小值参与排序，得显式写
ORDER BY amount NULLS FIRST - GROUP BY 字段和 SELECT 中非聚合字段不一致 → PostgreSQL 严格报错，不像 MySQL 那样“宽容”
PERCENTILE_CONT 性能差？怎么优化
这个函数本质要对每组数据做内部排序，数据量大时确实比 AVG 慢 3–10 倍。不是语法问题，是算法成本高。
实操建议：
- 确保
ORDER BY字段上有索引，例如CREATE INDEX idx_orders_city_amount ON orders(city, amount);，能显著加速 GROUP BY + PERCENTILE_CONT 组合 - 避免在超大数据集（如 >10M 行）上实时计算；可考虑物化视图定期预计算：
CREATE MATERIALIZED VIEW mv_city_median AS SELECT ... PERCENTILE_CONT... - 如果只要近似中位数，可用
tdigest扩展（需安装），tdigest_percentile(tdigest_agg(amount), 0.5)速度提升明显，误差通常
和其他数据库的中位数写法对比要注意什么
迁移到 PostgreSQL 或写跨库兼容 SQL 时容易翻车。MySQL 8.0+ 有 PERCENT_RANK() 但没 PERCENTILE_CONT；SQL Server 用 PERCENTILE_CONT 但语法相同；Oracle 则是 PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY ...) 完全一致。
关键差异点：
- PostgreSQL 要求
PERCENTILE_CONT参数必须是 numeric 常量（如0.5），不能是列或表达式；Oracle 允许，MySQL 不支持该函数 - 当输入为空组（如某城市无订单），PostgreSQL 返回 NULL；SQL Server 默认报错，需加
WITHIN GROUP的空处理逻辑 - 浮点精度：PostgreSQL 默认返回
double precision，若字段是numeric(10,2)，结果可能变成1234.5000000000002，必要时用ROUND(..., 2)截断
最常被忽略的一点：它不支持并行执行计划（截至 PG 15），即使开了 max_parallel_workers_per_gather，该函数仍强制单线程执行 —— 大表聚合前务必评估时间成本。
