sql无内置中位数函数，推荐用percentile_cont(0.5) over(partition by user_level order by amount)计算分组中位数，需注意null处理、数据类型和mysql旧版本兼容性问题。
直接说结论：SQL 里没有内置中位数函数，但用 PERCENTILE_CONT（标准 SQL）或 PERCENTILE_DISC 配合 PARTITION BY 可以按用户等级分组算消费中位数；MySQL 8.0+ 和 PostgreSQL 支持，旧版 MySQL 必须手写变量模拟，且结果可能不准。
用 PERCENTILE_CONT(0.5) 按等级分组求中位数（推荐）
这是最接近“标准解法”的方式，适用于 PostgreSQL、SQL Server、Oracle、BigQuery 和 MySQL 8.0+。它基于连续分布插值，对偶数个样本会返回两个中间值的平均值，语义上更符合统计学中位数定义。
关键点：
-
PERCENTILE_CONT(0.5)必须搭配OVER()，且ORDER BY是必需的（不能省略），否则报错Window function requires an ORDER BY clause - 要按用户等级分层，必须用
PARTITION BY user_level，不是GROUP BY - 该函数返回的是窗口内值，所以外层通常需配合
DISTINCT或GROUP BY去重，否则每行都重复输出相同中位数
SELECT DISTINCT
user_level,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY amount)
OVER (PARTITION BY user_level) AS median_amount
FROM orders;
为什么不用 PERCENTILE_DISC(0.5)？
PERCENTILE_DISC 返回排序后实际存在的某个值（不插值），对偶数个样本会取下中位数（即第 n/2 个），结果可能偏保守。比如 [100, 200, 300, 400]，PERCENTILE_CONT 返回 250，PERCENTILE_DISC 返回 200。
适用场景：
- 你明确要求结果必须是原始数据中的某一条（例如审计合规场景）
- 数据库不支持
PERCENTILE_CONT（如旧版 Redshift） - 性能敏感且数据量极大——
DISC版本在部分引擎中略快（但差异通常可忽略）
写法几乎一致，只换函数名：
PERCENTILE_DISC(0.5) WITHIN GROUP (ORDER BY amount) OVER (PARTITION BY user_level)
MySQL 5.7 或更低版本怎么办？
没有窗口函数，也不能用 PERCENTILE_*。常见“变量法”容易在并发查询或优化器重排时出错，尤其当 ORDER BY 和变量赋值顺序不一致时，中位数可能全错。
更稳的替代方案：
- 用子查询 +
ROW_NUMBER()模拟（仅限 MySQL 8.0+，否则仍不可用） - 应用层拉取各等级的
amount列表，用 Python/Java 算中位数（推荐：逻辑清晰、可控性强） - 如果必须在 SQL 层解决且无法升级，先用
GROUP_CONCAT拼接再用 UDF 解析——但生产环境不建议，维护成本高且有长度限制
典型翻车点：@row:=@row+1 在无显式 ORDER BY 的子查询中行为未定义，MySQL 官方文档明确警告过。
别漏掉 NULL 和数据类型陷阱
PERCENTILE_CONT 默认会自动过滤 NULL 值，这点没问题；但如果你的 amount 是字符串型（比如带单位 “¥199”），函数会静默转成 0 或报错 Invalid double value，取决于引擎。
检查项：
- 执行前先跑
SELECT COUNT(*), COUNT(amount) FROM orders WHERE user_level = 'VIP'，确认非空值数量是否合理 - 用
CAST(amount AS DECIMAL(10,2))显式转换，避免隐式转换引发精度丢失或截断 - 若中位数结果异常（如全是 0 或
NULL），优先查amount字段实际类型和空值率，而不是调函数参数
中位数计算本身不难，难的是确认你喂给它的数据干净、有序、类型正确——窗口函数不会替你做清洗。
