ROW_NUMBER()配合PARTITION BY user_id ORDER BY created_at DESC, id DESC最可靠，需子查询过滤rn=1；必须建(user_id, created_at)联合索引，避免GROUP BY或子查询性能陷阱。
用窗口函数 ROW_NUMBER() 按用户分组排序取最新
最可靠、可读性最强的方式是用 ROW_NUMBER() 配合 PARTITION BY user_id ORDER BY created_at DESC。它能明确按每个用户的时间倒序编号，取 rn = 1 就是最新订单。
注意：必须确保时间字段（如 created_at）不为空且类型正确（TIMESTAMP 或 DATETIME），否则排序会出错；如果存在多条同秒订单，ROW_NUMBER() 会任意选一条，若需稳定结果，建议加上主键（如 id）作为第二排序条件：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC)
- MySQL 8.0+、PostgreSQL、SQL Server、Oracle 均支持该写法
- SQLite 3.25+ 支持，但旧版不支持窗口函数
- 避免在子查询里用
SELECT *，只查需要字段，减少临时表开销
用 GROUP BY + 聚合函数会漏数据
常见错误是写成 SELECT user_id, MAX(created_at), order_id FROM orders GROUP BY user_id —— 这里的 order_id 是不确定的，MySQL 可能返回任意一行的 order_id，PostgreSQL 和 SQL Server 直接报错：column "order_id" must appear in the GROUP BY clause or be used in an aggregate function。
即使 MySQL 允许执行，结果也不可信，因为 MAX(created_at) 和对应行的 order_id 不一定来自同一记录。
- 别依赖 MySQL 的
sql_mode宽松模式来“绕过”这个问题 -
MAX(id)也不等于最新订单，除非id严格自增且插入顺序与时间完全一致（生产环境往往不满足）
用关联子查询性能容易崩
写成 WHERE created_at = (SELECT MAX(created_at) FROM orders o2 WHERE o2.user_id = o1.user_id) 看似直观，但对大表极不友好：外层每行都会触发一次子查询，复杂度接近 O(n²)。
- 当用户数超万、订单量超百万时，响应可能从毫秒级变成秒级甚至超时
- 如果
(user_id, created_at)没建联合索引，性能更差 - 存在时间相同多条记录时，可能返回多行——这不是“最新一条”，而是“最新时间的所有订单”
不同数据库的兼容写法要点
如果必须兼容老版本 MySQL（
SELECT o1.* FROM orders o1 LEFT JOIN orders o2 ON o1.user_id = o2.user_id AND o1.created_at < o2.created_at WHERE o2.id IS NULL;
原理是：找不出“同一用户、时间更晚”的订单，那它就是最新的。但要注意：
- 必须有索引
(user_id, created_at)，否则LEFT JOIN会全表扫描 - 时间字段允许
NULL时，NULL会被忽略，导致这些用户查不到结果 - PostgreSQL 和 SQL Server 中，这种写法比窗口函数慢一个数量级，仅作降级备选
真正难的不是写出某一种解法，而是根据数据量、数据库版本、是否允许重复时间、索引现状，选对那条路。很多线上慢查询，根源就在没意识到 GROUP BY 的非确定性，或低估了关联子查询的嵌套代价。
