SQL分组中位数计算方法详解

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()都没有，那就只能靠自连接或者应用层来曲线救国了。