rank()和dense_rank()返回全0或报错，主因是误用在where/group by中或缺失over(order by)；正确写法必须置于select列表，并确保over子句含order by，否则报错“window 'w' lacks an order by clause”。
MySQL 8.0里RANK()和DENSE_RANK()为什么返回全0或报错
MySQL 8.0+ 原生支持窗口函数，但RANK()和DENSE_RANK()必须配合OVER()子句使用，且不能出现在WHERE或GROUP BY中——这是最常见的报错根源。典型错误如：ERROR 3579 (HY000): Window function is not allowed in WHERE clause。
正确写法是把窗口函数放在SELECT列表里，用子查询或CTE承接结果后再过滤：
SELECT * FROM ( SELECT id, score, RANK() OVER (ORDER BY score DESC) AS rk FROM students ) t WHERE rk
-
RANK()和DENSE_RANK()不接受任何参数，括号不能空着（即不能写RANK），必须写RANK() - 排序字段必须明确写在
ORDER BY内，不支持用列别名（如ORDER BY rk会报错） - 如果表无主键或排序依据相同，结果顺序可能不稳定，建议加
ORDER BY score DESC, id ASC补全确定性
RANK()和DENSE_RANK()在并列时的行为差异
两者都处理重复值，但跳过方式不同：当两个并列第1名出现时，RANK()下一个是第3名，DENSE_RANK()下一个是第2名。这对榜单、TopN统计影响直接。
例如数据[95, 95, 87, 87, 80]：
-
RANK()→[1, 1, 3, 3, 5]（跳过2和4） -
DENSE_RANK()→[1, 1, 2, 2, 3]（不跳）
选哪个取决于业务定义：“第3名”是否允许空缺。排行榜常用DENSE_RANK()，合规审计类场景可能要求严格跳位，就得用RANK()。
按部门分组排名时PARTITION BY怎么写才不出错
分组排名靠PARTITION BY，但它不是GROUP BY——它只切分窗口范围，不聚合行数。常见误写是把它和GROUP BY混用，导致Unknown column或结果行数异常。
正确结构是：
SELECT dept, name, salary,
DENSE_RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS dept_rank
FROM employees;
-
PARTITION BY后只能跟字段名，不支持表达式（如PARTITION BY UPPER(dept)会报错） - 若需多级分组（如先按年份再按部门），写成
PARTITION BY year, dept，逗号分隔，不可嵌套 - 注意NULL值：默认被当作最小值参与排序，若想排除，加
WHERE dept IS NOT NULL提前过滤
性能差？大表上RANK()慢的几个硬约束
窗口函数必然触发临时排序，数据量超百万行时，RANK()可能比普通查询慢3–5倍。这不是写法问题，而是MySQL执行器限制。
- 必须有对应排序字段的索引，例如
ORDER BY score DESC就要有INDEX(score)，仅INDEX(score, id)也有效 - 复合分区+排序（如
PARTITION BY dept ORDER BY salary）需要联合索引INDEX(dept, salary)，顺序不能颠倒 - 避免在视图或存储过程中嵌套多层窗口函数，MySQL 8.0不优化嵌套窗口，会反复排序
真正的大宽表分组排名，得考虑预计算（如每天异步写入dept_rank字段）或换用ClickHouse这类分析型引擎——MySQL的窗口函数适合中小规模实时分析，不是OLAP底座。
