ROW_NUMBER() 必须用多个独立窗口函数实现多维度排名，每个绑定不同的 PARTITION BY 和 ORDER BY；它不支持并列排名，应改用 RANK() 或 DENSE_RANK()。
ROW_NUMBER() 不能直接“应用多个子句”，必须用多个独立的窗口函数
SQL 不允许在一个 ROW_NUMBER() 函数里写多个 ORDER BY 或嵌套多个排序逻辑。所谓“多个排名”，本质是并列调用多个 ROW_NUMBER()，每个绑定不同的 PARTITION BY 和 ORDER BY。常见错误是试图这样写：ROW_NUMBER() OVER (ORDER BY score DESC, time ASC) AS rank1, ROW_NUMBER() OVER (ORDER BY time ASC) AS rank2 —— 这语法完全合法，但容易忽略它们彼此独立、互不影响，不是“子句”关系。
- 每个
ROW_NUMBER()是一个完整窗口计算，可单独控制分区与排序 - 同一 SELECT 中可同时存在 5 个甚至更多不同配置的
ROW_NUMBER()，只要别名不重复 - 数据库不会自动“合并”或“联动”这些排名；比如按分数排第1的人，按耗时排可能是第17名，这完全正常
按部门分组排名 + 全局排名必须分开写两个 ROW_NUMBER()
这是最典型多维度排名场景：既要看出员工在本部门内的相对位置，又要知道在整个公司中的绝对位置。两者逻辑隔离，必须拆成两个计算字段。
SELECT name, dept, score, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY score DESC) AS dept_rank, ROW_NUMBER() OVER (ORDER BY score DESC) AS global_rank FROM employees;
-
PARTITION BY dept是部门内重置计数的关键，漏掉就变成全局连续编号 - 两个
ORDER BY都用DESC是为了分数越高排名越靠前；若混用（如一个DESC一个ASC），需确认业务含义是否真要“高分优先”和“早入职优先”并存 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 均支持；SQLite 3.25+ 也支持，但旧版不支持窗口函数
避免用 ROW_NUMBER() 实现“并列排名”，该用 RANK() 或 DENSE_RANK()
很多人想用 ROW_NUMBER() 实现“同分同名次”，结果写出错误逻辑：比如两人同为 95 分，ROW_NUMBER() 一定返回 1 和 2，不可能返回 1 和 1。这不是 bug，是设计如此。
- 需要跳过后续名次（95 分→第1名，94 分→第3名）：用
RANK() - 需要紧凑名次（95 分→第1名，94 分→第2名）：用
DENSE_RANK() -
ROW_NUMBER()只适合严格唯一序号场景，例如“按时间戳生成插入顺序号”“分页取第 N 条” - 强行用
ROW_NUMBER()模拟并列排名，需配合自连接或 LAG/LEAD 判断值变化，复杂且低效
性能隐患：多个窗口函数会各自扫描数据，大表慎用
每个 ROW_NUMBER() 都触发一次窗口计算，即使 PARTITION BY 和 ORDER BY 完全相同，数据库通常也不会复用中间结果（极少数优化器可能合并，但不可依赖）。
- 对千万级表，写 4 个不同配置的
ROW_NUMBER()，可能比单个慢 3–4 倍 - 确保涉及的排序字段（如
score、created_at）上有索引，尤其当ORDER BY无PARTITION BY时，相当于全局排序 - 如果只是临时分析，可先用
WHERE过滤出小结果集再算排名；生产 SQL 中应评估是否真需实时计算，还是可预计算存到冗余字段
真正麻烦的不是语法写法，而是想清楚“每个排名到底服务于什么决策”——是给运营看部门对比？给风控做异常耗时预警？还是导出报表强制要求“同分同名次”？没想清这点，光堆 ROW_NUMBER() 只会让逻辑越来越难维护。
