首页 > 数据库 >mysql8.0中如何用函数进行中位数计算_使用PERCENT_RANK窗口函数

mysql8.0中如何用函数进行中位数计算_使用PERCENT_RANK窗口函数

来源：互联网 2026-05-04 13:05:13

MySQL 8.0中如何用函数进行中位数计算：使用PERCENT_RANK窗口函数 PERCENT_RANK 能不能直接算中位数答案是：不能。虽然 PERCENT_RANK() 函数返回的是“相对排名百分位”（数值范围在0到1之间，首行固定为0），但它并不能保证第50%的位置恰好对应一个真实的数据

MySQL 8.0中如何用函数进行中位数计算：使用PERCENT_RANK窗口函数

PERCENT_RANK 能不能直接算中位数

答案是：不能。虽然 PERCENT_RANK() 函数返回的是“相对排名百分位”（数值范围在0到1之间，首行固定为0），但它并不能保证第50%的位置恰好对应一个真实的数据点。问题出在哪里呢？尤其是在数据行数为偶数时，真正的中位数往往落在两个数值之间，需要取平均值。而 PERCENT_RANK() 最多只能标记出最接近0.5的那一行（或两行），它本身没有自动计算平均值的逻辑。所以，这个函数更适合用来筛选“前10%”这类基于排名的场景，用它来直接计算中位数，就有点“用错工具”的味道了。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

用 PERCENT_RANK 模拟中位数的可行做法

当然，如果你因为某些原因必须使用 PERCENT_RANK()——比如现有的查询框架严重依赖它，或者你需要同时输出其他分位信息——也不是完全无路可走。我们可以通过结合排序和条件过滤来逼近中位数，具体思路是这样的：

首先，对目标列进行升序排序，并为每一行计算 PERCENT_RANK() OVER (ORDER BY value)。
接着，找出 PERCENT_RANK 值最接近0.5的行。理论上可以用 ABS(PERCENT_RANK() - 0.5) = (SELECT MIN(ABS(PERCENT_RANK() - 0.5)) FROM ...) 这样的条件，但要注意，MySQL 8.0不允许在窗口函数后直接嵌套聚合函数，这就需要借助CTE（公共表表达式）或派生表来绕开限制。
一个更稳妥、但也更偏离 PERCENT_RANK 原意的做法是：用两个子查询分别取出“小于等于50%分位的最大值”和“大于等于50%分位的最小值”，然后对它们求平均。不过，这么做的本质已经和手动使用 ROW_NUMBER 的方案相差无几了。

下面是一个简化版的示例，它返回一个近似的中位数，但请注意，这并非严格的数学定义上的中位数：

WITH ranked AS (
  SELECT value, PERCENT_RANK() OVER (ORDER BY value) AS pr
  FROM t
)
SELECT A VG(value) FROM ranked WHERE pr IN (
  (SELECT MAX(pr) FROM ranked WHERE pr <= 0.5),
  (SELECT MIN(pr) FROM ranked WHERE pr >= 0.5)
);

为什么推荐改用 ROW_NUMBER + COUNT 更可靠

既然 PERCENT_RANK() 这么麻烦，有没有更优雅的方案呢？答案是肯定的。虽然MySQL 8.0没有内置的中位数函数，但使用 ROW_NUMBER() 配合总行数计数，可以精确地处理数据量为奇数和偶数的两种情况，而且性能表现通常更可控。它的优势很明显：

ROW_NUMBER() OVER (ORDER BY value) 能为每一行分配一个唯一的序号（从1开始），清晰明了。
COUNT(*) OVER() 可以方便地获取总行数 n。这样一来，中位数的位置就很容易确定了：奇数时是 (n+1)/2，偶数时则是 n/2 和 n/2+1 这两个位置。
更重要的是，它能避免 PERCENT_RANK 在遇到大量重复值时产生的“并列排名”问题。想象一下，如果有5行数据的值完全相同，PERCENT_RANK 会全部返回0，根本无法区分，而 ROW_NUMBER 则不会出现这种尴尬。

来看一个典型的、兼容奇偶行数的写法：

WITH numbered AS (
  SELECT value, ROW_NUMBER() OVER (ORDER BY value) AS rn, COUNT(*) OVER() AS cnt
  FROM t
)
SELECT A VG(value) FROM numbered WHERE rn IN (FLOOR((cnt + 1) / 2), CEIL((cnt + 1) / 2));

容易被忽略的边界情况

无论选择哪种基于窗口函数的方案，有几个边界情况必须小心处理，否则很容易掉进坑里：

空值处理：ORDER BY value 在MySQL 8.0中默认会将 NULL 值排在最前面。如果业务逻辑要求忽略 NULL，务必记得加上 WHERE value IS NOT NULL 条件。
空表情况：如果查询的表是空的，COUNT(*) OVER() 会返回0。此时，FLOOR((0+1)/2) 的计算结果是0，会导致 rn IN (0,1) 查不到任何行，最终返回 NULL。这从逻辑上看是正确的，但需要确认你的应用程序是否能妥善处理这个 NULL 结果。
重复值的语义：ROW_NUMBER 会给重复值分配不同的序号，这保证了位置的唯一性，但你需要思考这是否符合业务上对“中间位置”的定义。这一点上，它比 PERCENT_RANK 的行为更透明、更可预期。