在SQL中如何利用ROW_NUMBER函数实现数据去重与分页-SQL-PHP中文网

row_number()本身不直接去重，但通过partition by分组、order by排序（如created_at desc）、外层where rn=1筛选，可精准实现“每组留一条”；其严格唯一编号特性优于rank()/dense_rank()，避免并列导致多行保留。

在sql中如何利用row_number函数实现数据去重与分页

ROW_NUMBER() 去重：只保留每组第一条记录

ROW_NUMBER() 本身不直接去重，但配合子查询或 CTE 可实现「按某字段去重，留最新/最旧一条」的效果。关键在于用 ORDER BY 控制“哪条算第一”。比如按时间倒序，ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) 就能为每个 user_id 标出最新记录为 1。

常见错误是忽略 PARTITION BY 或写错排序方向：不加 PARTITION BY 整张表只编一次号；用 ASC 却想留最新数据，结果留了最老的。

必须搭配 PARTITION BY 指定去重维度（如 email、order_no）
去重后要过滤，只能用外层查询套一层，不能在窗口函数所在层级用 WHERE rn = 1

示例：保留每个 product_id 最高价的那条记录：

SELECT * FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY product_id ORDER BY price DESC) AS rn
  FROM products
) t WHERE rn = 1;

ROW_NUMBER() 分页：比 OFFSET 更稳定但需注意索引

用 ROW_NUMBER() 实现分页，本质是给全结果集编号再取区间，例如第 2 页（每页 10 条）就是 WHERE rn BETWEEN 11 AND 20。它比 OFFSET 10 LIMIT 10 在大数据量下更可控——因为 OFFSET 仍要扫描前 10 条，而 ROW_NUMBER() 的性能取决于 OVER 中的排序字段是否有索引。

容易踩的坑是没意识到排序字段无索引时，整个 OVER 子句会触发全表排序，比 OFFSET 还慢。

ORDER BY 字段必须有索引，否则分页查询可能秒变慢查询
不能把 ROW_NUMBER() 放在 WHERE 里直接用（语法报错），必须嵌套子查询
如果分页字段有重复值（如多个记录 created_at 相同），ROW_NUMBER() 会任意排序，导致同一页数据不稳定；此时建议补一个唯一字段（如 id）进 ORDER BY，例如 ORDER BY created_at DESC, id DESC

去重 + 分页合并写法：先去重再编号

实际业务中常需要「对去重后的结果分页」，比如「每个用户只显示一条最新订单，并分页展示前 20 条」。这时不能先分页再去重，必须先用 ROW_NUMBER() 去重，再对去重结果再次编号分页。

Multi-Brain Protocol

一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。

下载

错误做法是只用一层 ROW_NUMBER()，既分区又分页，逻辑上就矛盾——分区是按用户分，分页是按全局序号分，两者粒度不同。

必须两层嵌套：内层去重（PARTITION BY user_id ORDER BY updated_at DESC），外层分页（ORDER BY updated_at DESC, id DESC）

示例：

SELECT * FROM (
  SELECT *, ROW_NUMBER() OVER (ORDER BY updated_at DESC, id DESC) AS rn
  FROM (
    SELECT *,
           ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS dup_rn
    FROM orders
  ) t WHERE dup_rn = 1
) t2 WHERE rn BETWEEN 11 AND 20;