这段处理的关键，其实就三步：先用 ROW_NUMBER() 按 user_id 分组，再按 created_at 倒序排列，拿到每组的第一条记录。

同时要用 COALESCE 兜住空值问题，再补上 id 这类唯一字段，避免结果重复。

性能上也不能忽视，最好建立 (user_id, created_at DESC, id DESC) 这个联合索引，查询效率通常会稳定得多。

用 ROW_NUMBER() 按用户+时间倒序标序号

核心思路是：对每个用户的所有订单，按下单时间从新到旧排序，取序号为 1 的那条。

关键不是“最后一条”，而是“最新时间那条”。数据库里没有隐含的“末笔”概念，得靠时间字段显式定义。

假设表叫 orders，有字段 user_id、order_id、created_at：

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

注意点：

• PARTITION BY user_id 确保分组只在同用户内生效
• ORDER BY created_at DESC 是主排序，但若存在同一秒多单，必须加次级排序（如 order_id DESC）避免 ROW_NUMBER() 非确定性结果
• 别用 RANK() 或 DENSE_RANK()，它们会对相同时间的订单给相同序号，导致“末笔”查出多条

遇到 created_at 为空或重复怎么办

真实数据常有脏数据：部分订单没时间戳，或多个订单共用同一毫秒级时间。

这时候直接 ORDER BY created_at DESC 会出问题。

稳妥做法是补一个确定性兜底排序：

• 先用 COALESCE(created_at, '1970-01-01') 把空值统一归到最早，避免它们被误选为“末笔”
• 再叠加 order_id DESC（前提是 order_id 是自增或时间相关递增）
• 如果连 order_id 都不可靠，考虑加个 id（主键）作为最终排序依据，确保每行唯一可比

示例修正：

ROW_NUMBER() OVER (
PARTITION BY user_id 
ORDER BY COALESCE(created_at, '1970-01-01') DESC, id DESC
) AS rn

性能差？检查是否建了联合索引

窗口函数本身不慢，慢在没索引支撑的 PARTITION BY + ORDER BY 组合。

执行计划里如果看到 Sort 节点占大头，基本就是缺索引。

针对上面查询，最有效的索引是：

CREATE INDEX idx_user_created_id ON orders (user_id, created_at DESC, id DESC);

注意三点：

• 顺序必须是 user_id 在前，对应 PARTITION BY
• created_at DESC 要和 ORDER BY 方向一致，否则无法跳过排序
• 最后加上 id（或 order_id）是为了覆盖查询，避免回表

MySQL 8.0 之前没法用窗口函数？用 LEFT JOIN 自关联模拟

老版本 MySQL 或某些 OLAP 引擎不支持窗口函数时，得换思路：找“不存在更新订单”的订单。

逻辑是：对每个 o1 订单，查是否存在同用户、时间更晚的 o2 订单；找不到，o1 就是末笔。

SELECT o1.*
FROM orders o1
LEFT JOIN orders o2 
ON o1.user_id = o2.user_id 
AND o2.created_at > o1.created_at
WHERE o2.order_id IS NULL;

这个写法看着简单，但实际容易翻车：

• 空值参与 > 比较结果为 UNKNOWN，导致漏数据，必须提前过滤或用 COALESCE
• 没有索引时，复杂度是 O(n)，千万级订单基本跑不动
• 如果时间精度低（比如只到天），且同天多单，仍可能返回多条，得额外加 MAX(id) 子查询收口

真要兼容老版本，优先升级；实在不行，就老老实实加索引 + 控制数据质量。

结论

窗口函数不是银弹，但只要 PARTITION BY 字段区分度高、时间字段靠谱、索引到位，“末笔订单”这种需求其实非常干净。

最容易被忽略的，其实是时间字段本身的可信度。

别急着写 SQL，先看几条脏数据长什么样。