首页 > 数据库 >SQL分组数据后如何获取每组最新记录_使用ROW_NUMBER窗口函数

SQL分组数据后如何获取每组最新记录_使用ROW_NUMBER窗口函数

来源：互联网 2026-04-23 14:11:04

SQL分组数据后如何获取每组最新记录在数据库查询中，一个经典且高频的需求是：从每组数据里，精准地捞出最新的那条记录。听起来简单，但实际操作时，新手甚至老手都可能踩进几个“坑”。今天，我们就来把这几个关键点彻底理清。不能直接用 GROUP BY 配合 MAX(time) 拿最新记录，因为 id 和

SQL分组数据后如何获取每组最新记录

在数据库查询中，一个经典且高频的需求是：从每组数据里，精准地捞出最新的那条记录。听起来简单，但实际操作时，新手甚至老手都可能踩进几个“坑”。今天，我们就来把这几个关键点彻底理清。

不能直接用 GROUP BY 配合 MAX(time) 拿最新记录，因为 id 和 user_id 可能不属于同一行，MySQL 5.7 严格模式会报错；ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 使用，否则无法正确分组排序；子查询或 CTE 是最稳妥的嵌套方式，因 WHERE 执行早于窗口函数；需注意 NULL 值、并列时间及分组键为 NULL 的影响。

SQL分组数据后如何获取每组最新记录_使用ROW_NUMBER窗口函数

长期稳定更新的攒劲资源： >>>点此立即查看<<<

为什么不能直接用 GROUP BY 配合 MAX(time) 拿最新记录

这是最常见的误解。很多人会想当然地写出类似 SELECT id, user_id, MAX(created_at) 的查询，以为数据库会自动把 MAX(created_at) 对应的那行 id 和 user_id 匹配给你。但事实是，GROUP BY 只管聚合，它并不知道你想要的 id 和 user_id 该来自哪一行——它们很可能和那个最大的时间戳不在同一行。结果就是数据错乱。

更严格地说，在 MySQL 5.7 的严格模式下，这种写法会直接报错：Expression #1 of SELECT list is not in GROUP BY clause。即便某些模式不报错，返回的结果也基本不可信。所以，这个捷径从一开始就走不通。

ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 使用

既然 GROUP BY 不行，窗口函数 ROW_NUMBER() 就成了首选。但这里有个关键：它必须明确两件事——“按什么分组”和“组内怎么排序”。少了任何一个，结果都会南辕北辙。

正确写法：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)。意思很清晰：按用户分组，组内按时间降序排，然后编号。
典型错误：ROW_NUMBER() OVER (ORDER BY created_at DESC)。漏了 PARTITION BY，这就变成了给全表排序编号，完全失去了分组的意义。
危险写法：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at ASC)。排序方向搞反了，用 ASC 拿到的是每组最老的记录，而不是最新的。

看，一个字母之差，结果天差地别。

子查询或 CTE 是最稳妥的嵌套方式

算出编号后，下一个问题来了：怎么筛选出编号为1的记录？你可能会想直接在 WHERE 子句里写 rn = 1。但抱歉，这行不通。因为 WHERE 子句的执行顺序在 SELECT 之前，此时窗口函数计算出的 rn 列还不存在。

怎么办？必须分层处理。最清晰的方式是使用 CTE（公用表表达式），这在 PostgreSQL、SQL Server 和 MySQL 8.0+ 中都支持：

WITH ranked AS (
  SELECT *,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
  FROM orders
)
SELECT id, user_id, amount, created_at
FROM ranked
WHERE rn = 1;

如果数据库版本较旧（比如 MySQL 5.x），不支持 CTE，那就用派生表（子查询）来实现同样的逻辑：

SELECT id, user_id, amount, created_at
FROM (
  SELECT *,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
  FROM orders
) t
WHERE rn = 1;

这两种方式本质一样，都是先构建一个包含排序列的中间结果集，再从中过滤。结构清晰，不易出错。

注意 NULL 值和并列时间对 ROW_NUMBER 的影响

你以为这样就万无一失了吗？还有几个细节值得警惕。

首先是并列时间。ROW_NUMBER() 会严格为每一行生成唯一的序号，即使两条记录的 created_at 完全相同，它也会强行分出1和2。如果你希望时间并列的记录都能被保留（比如同一个用户在同一秒创建了两笔订单），那就需要改用 RANK() 或 DENSE_RANK()。不过，这又会带来新的问题——它们不保证每组只返回一条记录，可能还需要额外的去重逻辑。

其次是NULL值处理。如果 created_at 字段允许为 NULL，排序时就要小心了。不同数据库对 NULL 在排序中的位置有不同默认行为（例如 PostgreSQL 默认 NULLS LAST，而 Oracle 默认 NULLS FIRST）。为了结果可控，建议显式声明：ORDER BY created_at DESC NULLS LAST。

最后，也是最容易忽略的一点：分组键本身为 NULL。当 PARTITION BY user_id 时，所有 user_id IS NULL 的记录会被归为同一组。这未必符合业务逻辑。如果这不是你想要的，务必提前用 WHERE 过滤掉这些记录，或者使用 COALESCE(user_id, -1) 之类的函数给 NULL 一个明确的占位值。

把这些细节都考虑到，你的“取每组最新记录”查询才算真正稳健可靠。

侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述