SQL求中位数：一场跨数据库的方言大乱斗
处理数据时，中位数这个指标经常让人又爱又恨。均值容易受极端值干扰，中位数则稳健得多。但问题是，在SQL的世界里，不同数据库对中位数的“方言”差别太大了，简直像一场各说各话的武林大会。今天咱们就来拆解一下几个主流数据库的解法，看看各自的“独门秘籍”和“坑”在哪里。
PostgreSQL：原生派，一招定乾坤
PostgreSQL无疑是这场较量里的“正规军”。它原生支持 PERCENTILE_CONT(0.5)，这是标准的ANSI SQL窗口函数，用起来非常爽利。它的核心逻辑是连续插值——哪怕你的数据全是整数，它也会给你算出一个精确的浮点数。
使用时有两大分支需要区分：
- 聚合场景：每组分一个结果。直接在
SELECT后面写，搭配GROUP BY就行。 - 窗口场景：每行都显示所属组的中位数。这时候要用
OVER (PARTITION BY ...)。
举个例子，你想知道每个商品分类的价格中位数：
SELECT category,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY price) AS median_price
FROM products
GROUP BY category;
值得留意的一点是，如果price字段全是整数，比如[1,2,3,4]，结果会是2.5。这不是bug，是插值法的设计使然。它通过线性插值来保证结果更平滑，而不是简单取中间两个数的均值。
MySQL：手动派，靠思路和技巧硬算
MySQL（8.0+用户）这边就没那么幸运了，没有现成的中位数函数。那就得自己动手，丰衣足食。核心思路就两步：排序，然后找到中间位置。
具体操作是：对每个分组按目标列排序，标上序号；然后根据总行数的奇偶情况，奇数取第 (n+1)/2 行，偶数取第 n/2 和 n/2+1 行的平均值。
这里有个隐藏的坑：ROW_NUMBER() 必须在子查询或CTE（公用表表达式）里先完成排序和编号。不能图省事，直接在外部 GROUP BY 里面嵌套调用，否则要么报错，要么逻辑混乱。来看一个CTE的经典写法：
WITH ranked AS (
SELECT category, price,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY price) AS rn,
COUNT(*) OVER (PARTITION BY category) AS cnt
FROM products
)
SELECT category,
A VG(price) AS median_price
FROM ranked
WHERE rn IN (FLOOR((cnt + 1) / 2), CEIL((cnt + 1) / 2))
GROUP BY category;
注意，这里用 FLOOR 和 CEIL 是为了统一处理奇偶情况：奇数行时，两个值相同，只取一行；偶数行时，正好取中间两行。这个写法清晰且健壮。
SQLite：硬核派，子查询的暴力美学
SQLite的情况就更特殊了，它直到3.25版本才开始支持窗口函数，而且连CEIL这类常用函数也没有。最稳妥（也是原始）的做法，是使用相关子查询来模拟：数一数有多少个值小于等于当前值，再和总数比对，找到那个“比它小的和比它大的都占一半”的数值。
这个方法的实操难点在于，如果排序字段有重复值，会匹配到多个候选值。解决方法是加一个唯一标识（比如主键id）来辅助排序，这样可以确保结果唯一。还要注意，这是个 O(n²) 复杂度的写法，数据量大了性能堪忧，别在超过1万行的表上直接跑。
这里给出一个简化版示例（假设price唯一）：
SELECT DISTINCT p1.category,
(SELECT p2.price
FROM products p2
WHERE p2.category = p1.category
AND (SELECT COUNT(*)
FROM products p3
WHERE p3.category = p1.category AND p3.price <= p2.price) >=
(SELECT COUNT(*) FROM products p4 WHERE p4.category = p1.category) / 2.0
AND (SELECT COUNT(*)
FROM products p3
WHERE p3.category = p1.category AND p3.price >= p2.price) >=
(SELECT COUNT(*) FROM products p4 WHERE p4.category = p1.category) / 2.0
LIMIT 1) AS median_price
FROM products p1;
跨库兼容？不存在的，放弃幻想
不同数据库对中位数的实现差异巨大，可以说是“鸡同鸭讲”。PERCENTILE_CONT 在PostgreSQL、Oracle、SQL Server里行为一致，但MySQL和SQLite就是没有。MEDIAN() 函数只在Oracle旧版本里存在，新版本官方也推荐用 PERCENTILE_CONT。SQLite甚至连CEIL函数都没有，只能用CAST(... AS INTEGER) 来处理向上取整。
所以，如果你的项目必须跨数据库运行，那基本只有两条路：
- 应用层解决： 把分组数据拉到Python、Ja va里，用
statistics.median或类似的库去算。灵活，但性能开销在数据传输上。 - 接受近似值： 比如用
A VG配合MIN/MAX来估算。这显然不是严格意义上的中位数，但在某些对精度要求不高的场景下也能凑合。
总而言之，实战中优先查清楚你当前数据库的版本和函数支持列表，千万别死记硬背别人家的语法。尤其是MySQL用户，如果你还在用5.x版本，连ROW_NUMBER()都没有，那就只能靠自连接或者应用层来曲线救国了。
