SQL查询如何实现分组内的中值过滤：绕开HA VING的陷阱
中值不能直接用 HA VING 过滤，因为 MEDIAN() 不是标准 SQL 聚合函数
如果你尝试在HA VING子句里直接写MEDIAN(score) > 85，大概率会碰壁。为什么呢？因为MEDIAN()这个函数，在绝大多数主流数据库（比如MySQL 8.0之前、PostgreSQL 13之前、SQL Server）里，压根就不是一个标准的聚合函数。执行时你会直接收到类似Unknown function 'MEDIAN'的错误提示。
即便像PostgreSQL 14+这样支持PERCENTILE_CONT(0.5)来计算中值的数据库，这个函数也不能直接用在HA VING里进行分组后过滤。问题的根源在于，中值的计算依赖于组内数据的完整排序，而HA VING子句只能引用那些已经计算好的聚合结果（比如A VG()、COUNT()）或者GROUP BY的列。这个执行顺序上的根本差异，让直接过滤中值的想法行不通。
正确做法：用窗口函数先算组内中值，再外层过滤
那么，正确的路该怎么走？核心思路其实很清晰：先分组排序求出中值，再把中值当作一个普通列来参与条件判断。这意味着你必须把查询拆成两层：内层查询（可以用子查询或者CTE）负责老老实实计算每个组的中值，外层查询再用WHERE来过滤。
具体到不同数据库，实现姿势略有不同：
- MySQL 8.0+：可以用
ROW_NUMBER()配合COUNT(*)来模拟中值的位置，或者利用PERCENT_RANK()和FIRST_VALUE()的组合拳。 - PostgreSQL：最省事，直接用
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY score)，在子查询里按GROUP BY department分组计算即可。 - SQL Server：使用
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY score) OVER (PARTITION BY department)，注意这是窗口函数写法，计算后需要去重再过滤。
来看一个PostgreSQL的示例，一目了然：
SELECT department, a vg_score
FROM (
SELECT
department,
A VG(score) AS a vg_score,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY score) AS median_score
FROM exam_results
GROUP BY department
) t
WHERE median_score > 85;
为什么不能把中值计算塞进 HA VING？
说到底，这是由HA VING子句的“工作职责”决定的。它的执行时机是在GROUP BY完成之后，此时它只能使用聚合函数产出的标量结果（比如COUNT()、A VG()）。而中值计算，本质上是一个“排序后定位”的操作，并非简单的归约聚合。
很多数据库引擎（尤其是旧版本）在聚合上下文中根本不支持调用排序逻辑。如果你强行尝试，通常会引发三种结果：
- 最直接的：语法错误，告诉你函数不存在。
- 运行时错误：提示“window function is not allowed in HA VING clause”。
- 更隐蔽的逻辑错误：如果误用了窗口函数，结果可能会因为未正确分区而导致重复计算，最终数据失真。
还有一个常被忽略的细节：HA VING子句里无法引用SELECT列表中定义的别名。所以，即便你在SELECT里用子查询算出了中值并命名为m，想在HA VING里写m > 85也是非法的。
性能与兼容性要注意的点
中值计算天生就比求平均值或计数要“重”一些，数据量大的时候尤其需要注意：
- PostgreSQL的
PERCENTILE_CONT会触发排序操作，如果经常按部门和分数查询，可以考虑在(department, score)上建立复合索引来加速。 - MySQL 8.0手动实现中值通常需要两遍扫描（一遍计数确定位置，一遍取第N/2行），使用
ROW_NUMBER()时务必记得加上PARTITION BY department ORDER BY score。 - 如果你的目的只是想“排除极端值后再求平均”，那么不妨换个思路，直接用
WHERE score BETWEEN ... AND ...预先过滤掉离群值，这往往比先计算中值再用HA VING过滤要快得多。
话说回来，真正让很多人卡住的，往往不是具体的语法怎么写，而是没有意识到中值计算和SUM()这类聚合操作在本质上的不同。一旦混淆了这个根本差异，所有试图在HA VING里搞定中值过滤的尝试，都注定会失败。
