MySQL中GROUP BY不保证子查询ORDER BY顺序，5.7+严格模式下会报错；可靠解法是MySQL 8.0+用ROW_NUMBER()窗口函数，5.7及更早用INNER JOIN关联聚合结果。
MySQL 的 GROUP BY 不会保留子查询里的 ORDER BY 顺序，所以“先排序再分组”在绝大多数情况下根本不可靠。 即使你写 SELECT * FROM (SELECT * FROM t ORDER BY created_at DESC) s GROUP BY user_id，MySQL 5.7+ 严格模式下会报错，5.7 之前也可能返回任意一行——不是最新那条，而是优化器随便挑的一条。
GROUP BY + 子查询 ORDER BY 为什么失效
MySQL 在执行 GROUP BY 时，会忽略子查询中的 ORDER BY（除非带 LIMIT），因为标准 SQL 规定：子查询不保证顺序，除非显式要求。更关键的是，GROUP BY 本身不定义“取哪一行”，它只负责分组聚合，非聚合字段的值来源未定义。
- 不加
LIMIT：子查询的ORDER BY被优化器直接丢弃，后续GROUP BY随机选行 - 加了
LIMIT 9999999：看似能“固定顺序”，但这是 hack，依赖 MySQL 内部实现，且LIMIT值必须大于总行数才有效，否则会漏数据 - MySQL 5.7 严格模式下：
SELECT id, user_id, MAX(created_at) FROM t GROUP BY user_id直接报错Expression #1 of SELECT list is not in GROUP BY clause
MySQL 8.0+ 推荐用 ROW_NUMBER() 窗口函数
窗口函数是唯一语义清晰、行为可预测的解法。核心是两步：先按分组键和排序字段打序号，再过滤序号为 1 的行。
- 必须写全
PARTITION BY和ORDER BY，漏掉任一都错：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) - 如果
created_at可能重复，建议补二级排序（如id DESC）确保结果稳定：ORDER BY created_at DESC, id DESC - 不能在同一个
SELECT里直接WHERE rn = 1，因为窗口函数在WHERE之后执行；必须用子查询或 CTE 包一层 - 示例：
SELECT id, user_id, amount, created_at FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC) AS rn FROM orders ) t WHERE rn = 1;
MySQL 5.7 及更早版本只能用关联子查询或自连接
窗口函数不可用，就得靠显式匹配“每组最大时间对应哪一行”。性能比窗口函数差，但语义明确、兼容性好。
- 推荐写法：用
INNER JOIN关联聚合结果，避免IN (SELECT ...)在大数据量下变慢SELECT o1.* FROM orders o1 INNER JOIN ( SELECT user_id, MAX(created_at) AS max_time FROM orders GROUP BY user_id ) o2 ON o1.user_id = o2.user_id AND o1.created_at = o2.max_time;
- 注意 NULL 值：如果
created_at允许为NULL，MAX()会忽略它们，可能导致没匹配到行；必要时加WHERE created_at IS NOT NULL - 如果存在多条同为最大时间的记录，这个写法会返回全部；若只要一条，得在
JOIN后再加GROUP BY或用ORDER BY id DESC LIMIT 1子句控制
真正容易被忽略的点是：**窗口函数的执行时机比 WHERE 早，但比 GROUP BY 晚；而关联子查询里，内层聚合和外层匹配必须字段完全一致，哪怕类型隐式转换（比如字符串 vs 数字）都会导致空结果。** 实际写的时候，先用小数据集验证 JOIN 条件是否真能命中，比盲目调优更省时间。
