在数据分析工作中，我们常常需要计算分组后的分位数指标，比如各部门薪资的中位数。很多朋友会首先想到窗口函数 PERCENT_RANK()，但实际操作后却发现，结果往往和预期对不上。今天，我们就来彻底厘清这个函数的“脾气”，并找到真正可靠的解决方案。
核心结论先摆在这里：PERCENT_RANK() 函数本身并不能直接给出分位数值（例如中位数对应的具体薪资），它返回的只是一个相对位置的比例。想要拿到真实的分位数，你需要配合 ROW_NUMBER() 和 COUNT() 等函数，或者直接改用 PERCENTILE_CONT 这类专用函数。
第一个坑：ORDER BY 子句绝不能省
这是新手最容易踩的雷区。如果你在写 PERCENT_RANK() 时漏掉了 ORDER BY，不同数据库的反应会不一样，但结果都是错的。在 PostgreSQL 和 SQL Server 中，这会直接导致语法错误；而在 MySQL 8.0+ 里，它可能“沉默”地返回全 0.0 或全 1.0 的值。记住，ORDER BY 不是可选项，而是强制性的语法组成部分。
- 正确的写法是：
PERCENT_RANK() OVER (PARTITION BY dept_id ORDER BY salary)。这表示“在每个部门内部，按照薪资升序排列，然后计算每一行的相对位置”。 - 不能用常量排序，比如
ORDER BY 1或ORDER BY 'x'，数据库不会接受这种写法。 - 如果只写
ORDER BY salary而省略PARTITION BY，那么计算就会基于整个表进行，这显然不是我们想要的“分组后”的效果。
为什么 PERCENT_RANK = 0.5 不等于中位数？
这是理解偏差的关键。很多人误以为，找到 PERCENT_RANK 值等于 0.5 的那一行，其对应的数值就是中位数。其实不然。PERCENT_RANK() 的计算公式是 (当前行的排名 - 1) / (组内总行数 - 1)。它只关心数据行的排序位置，与数值本身的分布情况毫无关系。
- 举个例子，一个部门有三条薪资记录：[1000, 2000, 3000]。那么
PERCENT_RANK结果分别是 0.0, 0.5, 1.0。中间那行（2000）的 0.5 恰好对应中位数，但这只是巧合。 - 如果变成四条记录：[1000, 2000, 3000, 4000]，
PERCENT_RANK结果会是 0.0, 0.333, 0.666, 1.0。你会发现，根本没有哪一行的值是 0.5。 - 退一步说，即使某行的
PERCENT_RANK值接近 0.5，它的salary也不一定等于数学定义上的中位数（尤其是在数据行数为偶数时，中位数需要取中间两个数的平均值）。
如何正确计算分组中位数？
既然不能硬套 PERCENT_RANK，那可靠的做法是什么？答案是结合使用 ROW_NUMBER() 和 COUNT(*) 这两个窗口函数来精确定位中位数的位置，然后再进行聚合计算。虽然不同数据库的具体语法略有差异，但背后的逻辑是相通的：
- 首先，计算每个组的总行数：
COUNT(*) OVER (PARTITION BY dept_id) AS cnt。 - 接着，为组内每一行按薪资排序编号：
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary) AS rn。 - 然后，确定中位数的位置。对于奇数行，中位位置是
(cnt + 1) / 2；对于偶数行，需要取中间两个位置（通常是FLOOR((cnt + 1)/2)和CEIL((cnt + 1)/2)）对应数值的平均值。 - 最后，通过聚合筛选出这些位置对应的行，并计算其薪资的平均值。像 Oracle 数据库还提供了更直接的
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary)函数来一步到位。
别忘了 NULL 值和性能这两个“隐藏关卡”
即使语法写对了，还有两个容易被忽略的细节：NULL值的处理和大量数据下的性能问题。这往往不是函数用错了，而是数据本身的特性带来的挑战。
- NULL 值处理：不同数据库对 NULL 在排序中的默认位置规定不同。例如，PostgreSQL 默认将 NULL 排在最前面，这可能导致
PERCENT_RANK计算结果全为 0.0，需要显式使用ORDER BY salary NULLS LAST来调整。而 MySQL 8.0+ 将 NULL 视为最小值，但不支持NULLS LAST语法，可能需要用COALESCE(salary, 某个极大值)来临时处理。 - 性能瓶颈：窗口函数的计算，尤其是带
PARTITION BY和ORDER BY的，本质上需要对每个分组内的数据进行排序。想象一下，如果某个部门有 50 万条薪资记录，这个排序操作对 I/O 和 CPU 的压力是巨大的。在大数据量场景下，如果对绝对精度要求不高，可以考虑使用近似计算函数，例如 BigQuery 的APPROX_PERCENTILE，或者先对数据进行采样再计算。
