如何用SQL实现多字段组合排序排名：窗口函数高级写法
ORDER BY 多字段排序后怎么加排名？
直接把 ROW_NUMBER() 塞进外层 ORDER BY 子句？这个操作是行不通的。窗口函数必须老老实实写在 SELECT 列表里。真正决定排名顺序的，是窗口函数内部那个 ORDER BY 子句，外层的排序对它没有影响。
一个常见的翻车现场是：明明用 ROW_NUMBER() OVER (ORDER BY score) 排好了名，一加上按 name 二次排序，结果就全乱了。问题根源在于，多字段的组合排序逻辑，必须完整地写进窗口函数的 ORDER BY 里。
- 核心规则：所有排序字段都得打包进窗口函数的
ORDER BY。比如：ROW_NUMBER() OVER (ORDER BY score DESC, name ASC)。 - 顺序很重要：这意味着先按
score降序排，分数相同的再按name升序排。调换这两个字段的顺序，得到的结果会截然不同。 - 注意NULL值：默认情况下，NULL在升序（ASC）时排在最前，降序（DESC）时排在最后。如果需要统一处理，PostgreSQL或Oracle可以显式使用
NULLS LAST，其他数据库可能需要用COALESCE函数先替换NULL值。
正确做法是将ROW_NUMBER()等窗口函数写在SELECT列表中，并在OVER子句内用ORDER BY指定多字段排序，如ROW_NUMBER() OVER (ORDER BY score DESC, name ASC)；分区排序需配合PARTITION BY且排序字段不能含分区字段。
同一组内多字段排序排名（PARTITION BY + 多级 ORDER BY）
遇到“在每个部门内部，先按薪资降序，再按入职时间升序排名”这类需求，就需要 PARTITION BY 和窗口 ORDER BY 联手了。这里有个关键原则：分区字段不能再出现在窗口的排序字段里，否则逻辑上就冲突了。
典型的错误用法是这样的：ROW_NUMBER() OVER (PARTITION BY dept ORDER BY dept, salary DESC)。一旦按 dept 分了区，组内所有行的 dept 值都相同，用它排序毫无意义，甚至可能导致查询执行计划效率降低。
- 正确写法：
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC, hire_date ASC)。 - 数据库支持度：MySQL 8.0+、PostgreSQL、SQL Server 2017+、Oracle 都完美支持。SQLite 从3.25版本开始也支持，但需要注意它不支持
NULLS FIRST/LAST语法。 - 理解分组上下文：
PARTITION BY字段值相同的所有行，会共享同一个分组“上下文”。窗口函数的计算（比如编号）只在这个组内独立进行。
RANK() vs DENSE_RANK() vs ROW_NUMBER() 的实际区别
这三个函数都依赖同一套 ORDER BY 逻辑，但处理“并列”情况的方式天差地别。选错了函数，业务逻辑就可能出错。举个例子，如果奖金发放规则要求“分数相同则名次相同，且名次号码连续不跳跃”，那就绝对不能使用 ROW_NUMBER()。
假设有这样一组数据：[(95, 'A'), (95, 'B'), (90, 'C')]，按分数降序排列：
ROW_NUMBER()→ 结果是 [1, 2, 3]。它严格递增编号，完全无视数值并列的情况。RANK()→ 结果是 [1, 1, 3]。它允许并列，但并列会占用名次号码，导致后续名次出现跳跃。DENSE_RANK()→ 结果是 [1, 1, 2]。它也允许并列，但名次号码是连续不间断的。
从性能角度看，三者没有显著差异。不过，RANK() 和 DENSE_RANK() 在内部需要做等值分组计算，在数据量极大时，可能会比 ROW_NUMBER() 稍微慢一点点。
MySQL 5.7 没窗口函数？替代方案只能靠自连接或变量
如果你还在使用 MySQL 5.7 或更早的版本，直接使用 ROW_NUMBER() 会收到一个明确的错误：FUNCTION xxx.ROW_NUMBER does not exist。这时候，有些人会尝试用用户变量来模拟，比如 SET @row := @row + 1。但在涉及复杂 JOIN 或 GROUP BY 的查询中，这种方法的执行顺序无法保证，极易导致排名错乱，可以说是个“暗坑”。
相对可靠的替代方案主要有两种：
- 自关联计数：通过左连接自己，统计比当前行“更好”的行数来推算名次。这种方法逻辑清晰，但只适合中小规模的数据集，数据量大时性能下降明显。
- 升级数据库：最一劳永逸的办法是升级到 MySQL 8.0+ 版本。它不仅完全支持标准SQL的窗口函数语法，其查询优化器对
PARTITION BY操作也有更好的索引支持，性能提升显著。
最后，在做跨数据库项目移植时，ROW_NUMBER() 的支持度最广，RANK() 次之。而像 NTILE() 这类更高级的窗口函数，在 SQLite 或旧版 SQL Server 中可能支持不佳。上线前，务必仔细核对目标数据库的官方文档。
