RANK()在GROUP BY后直接用会报错，因为GROUP BY先执行，RANK()作为窗口函数需基于未分组的原始行集计算，而GROUP BY已将多行聚合成单行，导致RANK()失去作用对象；正确做法是用PARTITION BY department实现分组内排名，而非依赖外部GROUP BY。
为什么RANK()在GROUP BY后直接用会报错？
RANK() 是窗口函数，不是聚合函数，不能和 GROUP BY 混用——这是最常见的误解起点。你写 SELECT ..., RANK() OVER (...) FROM t GROUP BY ... 时，数据库（如 PostgreSQL、MySQL 8.0+、SQL Server）会直接报错 column "xxx" must appear in the GROUP BY clause or be used in an aggregate function。因为 GROUP BY 先执行，而 RANK() 需要基于未分组的行集计算排名。
RANK() 必须配合 PARTITION BY 实现“分组内排名”
真正实现“每个分组内独立排名”，靠的是 OVER(PARTITION BY group_col ORDER BY sort_col)，不是靠外部 GROUP BY。PARTITION BY 把数据逻辑切块，RANK() 在每块内部单独排序并编号。
常见错误是把分组字段写在 SELECT 后但漏掉 PARTITION BY，结果所有行排在一个大序列里。
-
PARTITION BY department：按部门分组，每个部门内独立排名 -
ORDER BY salary DESC：组内按薪资降序，最高薪排第 1 - 注意：RANK() 对相同值赋予相同名次，后续跳号（如 1,1,3）；需要连续编号用
DENSE_RANK()
示例：
SELECT name, department, salary, RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS dept_rank FROM employees;
MySQL 5.7 或旧版不支持窗口函数怎么办？
MySQL 5.7 及更早版本没有 RANK()，强行用会报错 FUNCTION xxx.RANK does not exist。必须升级到 MySQL 8.0+，或改用变量模拟（但并发不安全、结果不可靠）。
如果无法升级，且数据量不大，可考虑应用层分组后排序；若必须 SQL 层解决，可用自连接计数（性能差，慎用于大表）：
SELECT e1.name, e1.department, e1.salary,
(SELECT COUNT(*) + 1
FROM employees e2
WHERE e2.department = e1.department
AND e2.salary > e1.salary) AS dept_rank
FROM employees e1;
这个写法在 department 数据倾斜时容易慢，且无法处理 salary 相同的情况（需加额外条件去重）。
ORDER BY 在窗口定义里写错位置会导致排名失效
很多人把排序写在最外层 ORDER BY，比如 RANK() OVER (PARTITION BY dept) ORDER BY salary DESC —— 这语法错误，ORDER BY 必须在 OVER 内部，否则 RANK() 默认按无序处理，结果随机或全为 1。
另一个坑是 ORDER BY 字段类型隐式转换：比如用字符串字段排序却期望数值顺序（'10' ），导致排名错乱。务必确认 <code>ORDER BY 表达式返回的是预期类型和顺序。
复杂排序场景建议显式转换：
RANK() OVER ( PARTITION BY category ORDER BY CAST(priority AS SIGNED), updated_at DESC )实际使用时，PARTITION BY 和 ORDER BY 的组合逻辑比函数名本身更关键；一旦分区键选错或排序依据模糊，排名结果就失去业务意义。
