Oracle的MEDIAN()不能直接与GROUP BY联用，必须使用OVER(PARTITION BY...)配合DISTINCT或CTE实现分组中位数计算，且需显式ORDER BY保证排序稳定。
Oracle 的 MEDIAN() 不能直接和 GROUP BY 一起用
你写 SELECT dept, MEDIAN(sal) FROM emp GROUP BY dept，Oracle 会报 ORA-00937: not a single-group group function。这不是语法错误，是设计限制：MEDIAN() 在 Oracle 中虽是聚合函数，但**不支持与 GROUP BY 混合使用**——它会被当作分析函数解析，而分析函数不能出现在纯聚合上下文中。
真正能跑通的写法只有两种：用 OVER (PARTITION BY ...)，或套一层 DISTINCT + 分析函数。前者更直观，也更常用。
-
MEDIAN(sal) OVER (PARTITION BY dept)返回每行对应部门的中位数，结果行数和原表一致 - 必须搭配
DISTINCT或子查询才能“压缩”成每组一行，例如：SELECT DISTINCT dept, MEDIAN(sal) OVER (PARTITION BY dept) AS median_sal FROM emp - 如果只想要每个部门一个值（比如报表汇总），
DISTINCT是最轻量的收口方式；用GROUP BY反而会触发报错
NULL 值自动被 MEDIAN() 忽略，但排序稳定性得自己管
MEDIAN() 在 Oracle 中默认跳过 NULL，这点不用额外加 WHERE sal IS NOT NULL。但它的排序行为依赖 ORDER BY 子句是否显式指定——如果你没写 OVER (PARTITION BY dept ORDER BY sal)，Oracle 会按内部顺序排，相同 sal 值的行可能每次执行顺序不同，导致中位数位置漂移（尤其在偶数行取平均时）。
- 务必显式写
ORDER BY，哪怕只是ORDER BY sal - 若
sal有大量重复值，建议补上唯一键保序，例如ORDER BY sal, empno - 不要依赖默认排序；测试时拿 4 行数据（比如
[100,200,200,300]）手动验证输出是不是200.0（中间两值平均）
别把 MEDIAN() 当窗口过滤条件用
你想“查出每个部门里薪资高于本部门中位数的员工”，不能写 WHERE sal > MEDIAN(sal) OVER (PARTITION BY dept)——WHERE 子句不接受窗口函数。这种需求必须拆成两步：先算中位数（子查询或 CTE），再 JOIN 或 WHERE 比较。
- 错误写法：
SELECT * FROM emp WHERE sal > MEDIAN(sal) OVER (PARTITION BY dept)→ 报错ORA-30483: window functions are not allowed here - 正确思路：用 CTE 先算中位数表，再关联原表：
WITH dept_med AS (SELECT dept, MEDIAN(sal) OVER (PARTITION BY dept) AS m FROM emp) SELECT e.* FROM emp e JOIN dept_med d ON e.dept = d.dept WHERE e.sal > d.m - 注意：CTE 中的
MEDIAN()仍需OVER，不能省略
Oracle 的 MEDIAN() 和其他数据库的语义差异
Oracle 的 MEDIAN() 返回的是精确中位数（偶数行时严格取中间两值平均），这点和 PostgreSQL 的 percentile_cont(0.5) 一致，但和 MySQL/SQL Server 手写 ROW_NUMBER() 方案容易出的“只取一个中间值”错误有本质区别。不过它不支持 APPROXIMATE 模式，大数据量下性能不如近似函数。
- 数据量超百万行时，
MEDIAN() OVER的排序开销明显，比COUNT(*)+ROW_NUMBER()更重 - 如果业务允许近似结果（比如监控看板），考虑改用
APPROX_PERCENTILE_CONT(0.5)（Oracle 21c+ 支持） - 跨库迁移时特别小心：PostgreSQL 没
MEDIAN()，MySQL 根本不认这个函数名，硬搬会直接失败
真正容易被忽略的点是：Oracle 的 MEDIAN() 看似简单，但它强制绑定分析函数语法，又不能进 WHERE，还对排序敏感——这些约束不是 bug，而是设计选择。用之前先确认你的场景到底要“每组一个值”还是“每行带一个值”，选错路径后续所有逻辑都得重写。
