应使用ROW_NUMBER()窗口函数配合子查询筛选rn=1：先PARTITION BY分组、ORDER BY created_at DESC排序编号，再外层WHERE rn=1获取每组最新完整记录；GROUP BY+MAX()仅返回时间戳，无法带回整行字段。
用窗口函数 ROW_NUMBER() 配合子查询最可靠
直接在 GROUP BY 后用 MAX(created_at) 只能取到时间戳，拿不到对应那条记录的其他字段。真正要“整行数据”，必须把排序和筛选拆开做——先按分组和时间排好序，再筛出每组序号为 1 的行。
典型写法是：外层查 WHERE rn = 1，内层用 ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY created_at DESC) 标记序号。注意 ORDER BY 必须明确指定方向（DESC），否则可能拿到最早的记录。
常见错误是漏掉 PARTITION BY 或写错分组字段，导致全表只排一次序；还有人误用 RANK()，当存在相同时间戳时会并列排名，rn = 1 可能返回多条，而 ROW_NUMBER() 严格保证唯一序号。
NOT EXISTS 关联子查询适合小数据量或需兼容老版本 MySQL
如果数据库不支持窗口函数（比如 MySQL 5.7 或某些嵌入式 SQLite 场景），可以用自关联 + NOT EXISTS：对每条记录，检查是否存在同组但时间更新的记录；若不存在，说明它就是最新的。
示例结构：
SELECT t1.* FROM orders t1
WHERE NOT EXISTS (
SELECT 1 FROM orders t2
WHERE t2.user_id = t1.user_id
AND t2.created_at > t1.created_at
);这个写法逻辑清晰，但性能随数据量增长明显下降——每行都要触发一次子查询扫描。索引很关键：(user_id, created_at) 复合索引能大幅减少子查询代价；单列索引效果有限。
避免用 GROUP BY + MAX() 直接拼字段
像 SELECT user_id, MAX(created_at), MAX(order_amount) 这种写法看似简洁，但 order_amount 并不一定来自时间最新的那条记录——它是该组里所有 order_amount 的最大值，和最新时间毫无关系。
MySQL 5.7 默认开启 ONLY_FULL_GROUP_BY，这种写法会直接报错：Expression #3 of SELECT list is not in GROUP BY clause；即使关掉，结果也是不可靠的。
有人试图用 GROUP_CONCAT(id ORDER BY created_at DESC LIMIT 1) 反向提取 ID 再关联，但字符串截取容易出错，且无法处理 NULL 或含逗号的字段值，属于高风险技巧，不推荐用于生产。
PostgreSQL 和 SQL Server 可用 DISTINCT ON 或 TOP (1) WITH TIES
PostgreSQL 提供了更简洁的语法：DISTINCT ON (user_id) *，配合 ORDER BY user_id, created_at DESC，能直接返回每组首行。注意 DISTINCT ON 字段必须是 ORDER BY 的前缀，否则报错。
SQL Server 2005+ 支持 TOP (1) WITH TIES，配合 ROW_NUMBER() 的 OVER 子句，可避免嵌套子查询：
SELECT TOP (1) WITH TIES * FROM orders ORDER BY ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC);
但要注意，WITH TIES 依赖 ORDER BY 中的窗口函数结果，不能单独用普通字段排序，否则行为不可控。
不同数据库的语法糖只是写法差异，底层逻辑一致：先定义“最新”的顺序，再取每组第一条。真正容易被忽略的是时间字段的 NULL 处理——ORDER BY created_at DESC 会让 NULL 排在最前面（默认行为），如果业务中允许未设置时间的脏数据，得加 NULLS LAST（PostgreSQL）或用 IS NULL 显式过滤。
