在交易系统、订单系统或日志分析中，经常遇到这样的需求：表里存着每个用户的多条交易记录，现在要查出每个用户最近一次的那条记录，包括交易时间、金额、状态等完整字段。很多初学者第一反应是用GROUP BY加MAX函数，结果发现查出来的数据张冠李戴——时间是最新时间，金额却是老金额。这篇文章就来详细讲解为什么会出现这个问题，以及如何用ROW_NUMBER窗口函数正确且高效地完成这类查询。
一、先看数据结构和错误示范
假设有一张交易流水表，结构如下：
CREATE TABLE trade_record (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL,
amount DECIMAL(10,2) NOT NULL,
status VARCHAR(20),
trade_time DATETIME NOT NULL
);
INSERT INTO trade_record (user_id, amount, status, trade_time) VALUES
(1001, 500.00, 'SUCCESS', '2024-01-05 10:00:00'),
(1001, 1200.00, 'SUCCESS', '2024-03-12 14:30:00'),
(1001, 300.00, 'FAILED', '2024-06-20 09:15:00'),
(1002, 880.00, 'SUCCESS', '2024-02-11 16:45:00'),
(1002, 2600.00, 'SUCCESS', '2024-05-08 11:20:00'),
(1003, 150.00, 'SUCCESS', '2024-04-01 08:00:00');很多新手会这样写：
SELECT user_id, MAX(trade_time), amount, status FROM trade_record GROUP BY user_id;
这条语句在MySQL的老版本（sql_mode未开启ONLY_FULL_GROUP_BY）下能跑，但结果是有问题的。MAX(trade_time)确实是该用户最大的时间，但amount和status是从组内任意一行随机取的，并不保证来自时间最大的那一行。这就是经典的分组取整行数据的陷阱，一旦数据量大了，错误的金额会带来严重的业务误判。
二、ROW_NUMBER的标准解法
窗口函数ROW_NUMBER的作用是：按照指定的分区和排序规则，给每一行分配一个连续的序号。思路很简单——按用户分区，按交易时间倒序排列，每组里序号为1的那行就是最近的交易记录。
SELECT user_id, amount, status, trade_time
FROM (
SELECT
t.*,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY trade_time DESC
) AS rn
FROM trade_record t
) x
WHERE x.rn = 1;这里有几个关键点需要理解。PARTITION BY user_id表示每个用户独立编号，互不干扰；ORDER BY trade_time DESC保证时间最新的排在最前面；外层通过WHERE rn = 1只保留每组的第一行。这种写法在MySQL 8.0以上、SQL Server、PostgreSQL、Oracle中都通用，语法基本一致。
ROW_NUMBER最大的优势在于灵活性。如果需求改成每个用户最近三条记录，只需要把过滤条件改成rn <= 3；如果要按每个用户每个状态分别取最新一条，把PARTITION BY改成PARTITION BY user_id, status即可。这种可扩展性是GROUP BY方案完全不具备的。
三、其他几种常见写法对比
除了ROW_NUMBER，还有几种常见的实现方式，各有适用场景。
第一种是关联子查询：
SELECT t.*
FROM trade_record t
WHERE t.trade_time = (
SELECT MAX(t2.trade_time)
FROM trade_record t2
WHERE t2.user_id = t.user_id
);这种写法在老版本MySQL（5.7及以下不支持窗口函数）中很常用，逻辑也清晰。但如果user_id上没有索引，子查询会对外层每一行都执行一次，数据量大时性能会明显下降。另外，如果同一用户存在两条trade_time完全相同的记录，这条查询会返回两行，可能不符合预期。
第二种是LEFT JOIN自关联：
SELECT t.*
FROM trade_record t
LEFT JOIN trade_record t2
ON t.user_id = t2.user_id
AND t2.trade_time > t.trade_time
WHERE t2.id IS NULL;原理是：如果找不到比自己时间更新的同用户记录，说明自己就是最新的。这种写法在特定索引结构下表现不错，但语义比较绕，后续维护成本高，一般不推荐。
第三种是ROW_NUMBER的孪生兄弟RANK和DENSE_RANK。三者的区别在于处理并列值：ROW_NUMBER严格唯一编号，即使值相同也会强排出1、2、3；RANK遇到相同值编同号并跳过后续序号；DENSE_RANK遇到相同值编同号但不跳号。如果希望时间戳相同的记录都查出来，把ROW_NUMBER换成RANK即可：
SELECT user_id, amount, status, trade_time
FROM (
SELECT t.*,
RANK() OVER (PARTITION BY user_id ORDER BY trade_time DESC) AS rk
FROM trade_record t
) x
WHERE x.rk = 1;四、实战中的注意事项
第一，排序字段的唯一性问题。如果只按trade_time排序，同一用户同一毫秒的两笔交易只保留一条，另一条会被丢弃。稳妥的做法是在排序末尾追加一个唯一字段兜底，例如ORDER BY trade_time DESC, id DESC，这样结果就是确定性的，不会因为数据库内部的行顺序不同而出现不同的查询结果。
第二，索引优化。对于大表，建议在user_id和trade_time上建立联合索引，例如：
CREATE INDEX idx_user_time ON trade_record (user_id, trade_time DESC);
窗口函数的排序如果能在索引层面完成，数据库可以省去昂贵的排序操作，性能提升非常明显。MySQL 8.0和PostgreSQL都支持降序索引，SQL Server会自动处理排序方向。
第三，注意NULL值。如果status或amount可能为NULL，ROW_NUMBER本身不受影响，但ORDER BY的字段如果出现NULL，在MySQL中NULL默认排在最前（升序时），倒序时排最后，必要时用ORDER BY trade_time DESC NULLS LAST（PostgreSQL支持）显式声明，避免最新记录因为时间为空而漏掉或错排。
总结一下，分组取最新记录这类需求，ROW_NUMBER加PARTITION BY是最通用、最易维护的方案。写的时候记住三件事：分区字段选对、排序字段加唯一列兜底、大表配好联合索引，基本就能覆盖绝大多数业务场景了。
ROW_NUMBERSQL窗口函数最近一次交易记录修改时间：2026-09-14 14:06:59