分组截取数据的核心，是在每个分组内部按业务规则排好顺序，再截取最靠前或最靠后的若干行。实现这个需求最常用的窗口函数就是 ROW_NUMBER()。它会在每一行上生成一个从 1 开始的整数编号，编号范围由分区决定，编号顺序由排序决定。理解这一点之后，很多以前需要自连接或临时表的操作，都可以简化成几行 SQL。
一、ROW_NUMBER 的编号逻辑：先分区再排序
窗口函数和普通聚合函数不同，它不会把多行合并成一行，而是在原始结果集的每一行上附加计算值。ROW_NUMBER() 的语法为 ROW_NUMBER() OVER (PARTITION BY 分区列 ORDER BY 排序列)，其中 PARTITION BY 负责划定分组边界，ORDER BY 决定组内编号的先后顺序。分区列可以省略，省略后整张结果集会被当成一个分区；排序列也可以省略，但数据库不保证编号顺序稳定，所以实际使用中建议显式写出排序规则。
举一个员工薪资表的例子：假设有 employee 表，包含 employee_id、department_id 和 salary 三个字段，现在要按部门分组、按薪资从高到低给每行编号。
SELECT
employee_id,
department_id,
salary,
ROW_NUMBER() OVER (
PARTITION BY department_id
ORDER BY salary DESC
) AS rn
FROM employee;
上面的查询会保留所有员工记录，同时新增一列 rn。PARTITION BY department_id 表示每个部门的编号都从 1 重新开始；ORDER BY salary DESC 表示部门内部薪资越高的行，rn 越小。如果同一个部门里有两个员工薪资完全相同，ROW_NUMBER 仍然会给它们分配不同的编号，谁先谁后由执行计划决定，这一点在业务上不能当作稳定依据。
它和 GROUP BY 的差别也很明显。GROUP BY department_id 会把每个部门压缩成一行，只能看到聚合结果，比如最高薪资或平均薪资，看不到具体哪些员工排在前面。而 ROW_NUMBER 保留所有明细行，只是在每行旁边追加一个序号。正因为这样，分组截取前 N 条数据不能只靠 GROUP BY 完成，窗口函数才是更合适的选择。
二、分组截取的三种典型写法
窗口函数在 SELECT 阶段才计算，不能在 WHERE 条件里直接引用别名。比如写出 WHERE rn <= 3 时，如果 rn 是 ROW_NUMBER() 的别名，数据库通常会提示别名不存在。要截取每组前 N 条，最通用的办法是先在子查询里完成编号，再在外层使用 rn 进行过滤。
SELECT employee_id, department_id, salary, rn
FROM (
SELECT
employee_id,
department_id,
salary,
ROW_NUMBER() OVER (
PARTITION BY department_id
ORDER BY salary DESC
) AS rn
FROM employee
) t
WHERE rn <= 3;
这个写法几乎所有支持窗口函数的数据库都能运行，包括 MySQL 8.0、PostgreSQL、SQL Server、Oracle 和 SQLite 3.25 及以上版本。它的缺点是当查询本身已经比较复杂时，子查询会让 SQL 嵌套层级变多，可读性下降。这时可以使用 CTE 把编号结果先提取出来，再基于 CTE 做筛选，逻辑会更清楚。
WITH ranked_employee AS (
SELECT
employee_id,
department_id,
salary,
ROW_NUMBER() OVER (
PARTITION BY department_id
ORDER BY salary DESC
) AS rn
FROM employee
)
SELECT employee_id, department_id, salary
FROM ranked_employee
WHERE rn <= 3;
部分云数仓和较新的数据库还提供了 QUALIFY 子句，允许直接按窗口函数结果过滤，例如 Snowflake、BigQuery 和 Oracle 21c。这样就不需要额外包一层子查询或 CTE。不过 QUALIFY 并不是所有数据库都支持，如果项目要求跨数据库迁移，建议优先使用子查询或 CTE 的标准写法。
从执行计划看，无论使用哪种写法，数据库通常都要根据 PARTITION BY 和 ORDER BY 指定的列做排序。如果数据量很大，排序可能成为性能瓶颈。可以在 (department_id, salary) 上建立复合索引，部分优化器能够利用索引顺序避免显式排序，从而降低内存和磁盘压力。
三、删除重复数据与分页优化
ROW_NUMBER 还经常用来清理逻辑重复的数据。例如日志表 log 中有 id、biz_id、created_at 和 content 字段，同一个 biz_id 可能因为重试或消息重复写入了多次。业务上只想保留每个 biz_id 最早的一条记录，可以先按 biz_id 分组、按 created_at 升序编号，再删除编号大于 1 的行。
WITH dup AS (
SELECT
id,
biz_id,
created_at,
ROW_NUMBER() OVER (
PARTITION BY biz_id
ORDER BY created_at ASC
) AS rn
FROM log
)
DELETE FROM log
WHERE id IN (
SELECT id FROM dup WHERE rn > 1
);
这段代码中，ORDER BY created_at ASC 会让每个 biz_id 分区内创建时间最早的行获得 rn = 1，其余重复行都会被编号为 2、3、4。删除时只删编号大于 1 的记录，天然保证了每个业务 ID 至少保留一条。如果要保留最新一条，把排序改成 created_at DESC 即可。
需要强调的是，删除重复行时使用 ROW_NUMBER 比 RANK 或 DENSE_RANK 更安全。因为后两者会处理并列值，如果存在完全相同的 created_at，可能出现多个 rn = 1 的情况，无法达到强制保留一条的目的。而 ROW_NUMBER 会硬性区分序号，刚好满足清理场景。
分页优化是另一个常见应用。传统 LIMIT 加偏移量的写法在深分页时效率较低，因为数据库需要扫描并丢弃大量前面的行。借助 ROW_NUMBER，可以先对主键排序并生成编号，再按编号区间取主键，最后回表获取完整数据。例如要取第 10001 到第 10100 行，可以先在 CTE 中对主键编号，再筛选这个编号区间，并用主键回表获取完整行。
WITH paged AS (
SELECT
id,
ROW_NUMBER() OVER (ORDER BY id) AS rn
FROM orders
)
SELECT o.*
FROM paged p
JOIN orders o ON o.id = p.id
WHERE p.rn BETWEEN 10001 AND 10100;
窗口分页的优势在于排序规则可以自定义，比如按创建时间或金额分页；劣势是如果排序列没有索引，仍然可能产生全表扫描和排序操作。实际使用时应结合执行计划判断是否比覆盖索引的 LIMIT 更优。对于数据量很大的表，最好让编号列和索引前缀保持一致，减少排序回表开销。
四、容易踩的坑与边界情况
并列值是第一个需要注意的问题。ROW_NUMBER 不合并并列项，如果业务上要求并列数据享有相同排名，应改用 RANK 或 DENSE_RANK。例如三个并列第一名的情况下，ROW_NUMBER 会编号为 1、2、3，RANK 会编号为 1、1、1、4，DENSE_RANK 则是 1、1、1、2。截取每组前 3 名时，如果存在并列薪资，使用 ROW_NUMBER 可能只取到并列人员中的一部分，而使用 RANK 又可能多返回行。业务口径必须先定清楚。
分区列出现 NULL 值也值得留意。在大多数数据库中，PARTITION BY 会把所有 NULL 归入同一个分区，和 GROUP BY 的行为一致。如果期望每个 NULL 都作为独立分区处理，需要先在查询中把 NULL 转换为唯一标识，例如拼接主键或使用 COALESCE 生成非空占位值。
性能方面，窗口函数排序可能占用大量内存，分区列基数越高，排序就越细碎。当排序数据超过工作内存时，数据库会溢出到磁盘，查询时间明显上升。优化时可以先确认业务是否真的需要所有分区都排序，如果只需要某个部门的数据，可以把过滤条件下推到子查询内部，减少参与窗口计算的行数。建立合适的复合索引也能帮助优化器减少排序开销。
总的来说，ROW_NUMBER 是一个非常适合分组截取和行级编号的工具。掌握它的执行阶段、和聚合函数的差异、以及与 RANK 系列函数的边界，能避免多数 SQL 调试中的疑惑。配合子查询、CTE 和合理的索引设计，它可以覆盖从 TopN 报表到重复数据清理的很多实际场景。
ROW_NUMBER分组排序窗口函数修改时间：2026-09-28 03:54:52