MySQL 5.7及更早版本不支持子查询中使用ORDER BY + LIMIT 1，会报错；即使8.0+支持，也存在排序非确定性风险，安全做法是用ROW_NUMBER()窗口函数配合外层WHERE rn=1筛选，或兼容老版本时用JOIN+MAX()。
子查询里用 ORDER BY + LIMIT 1 不可靠
直接在子查询里写 ORDER BY created_at DESC LIMIT 1 获取最新记录，看似合理，但 MySQL 5.7 及更早版本不支持子查询中带 LIMIT（会报错 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'）；即使在 8.0+ 支持，若子查询用于 IN 或 = 比较，仍可能因非确定性排序导致结果不稳定。
- 真正安全的做法是用窗口函数或关联子查询替代
LIMIT - 如果必须兼容老版本 MySQL，优先选
JOIN+MAX()方式 -
ORDER BY必须配合确定性排序字段（比如id和created_at组合），否则同秒插入的多条记录无法保证取到“真正最新”的那条
用 ROW_NUMBER() 窗口函数精准取每组最新一行
这是目前最清晰、可读性强且能处理“每个分组取最新”的典型场景（比如每个用户最新订单、每个设备最新上报）。
- MySQL 8.0+、PostgreSQL、SQL Server 都支持
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC) - 注意
ORDER BY中把id放在created_at后作为次级排序，避免时间相同导致顺序不可控 - 别漏掉外层过滤：
WHERE rn = 1，否则窗口函数只生成序号，不筛选数据
SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (
PARTITION BY user_id ORDER BY created_at DESC, id DESC
) AS rn
FROM orders
) t WHERE rn = 1;
WHERE ... IN (SELECT MAX(id) FROM ... GROUP BY) 的陷阱
这种写法常见但危险：用 MAX(id) 当“最新”代理，前提是 id 严格递增且与时间正相关。一旦有软删除、ID 复用、批量导入打乱顺序，就失效。
- 它不能表达“按时间最新”，只能表达“按主键最大”
- 若表无主键或主键非自增（如 UUID），
MAX(id)完全失去意义 - 性能上，
IN子查询在大数据量时可能退化为嵌套循环，比JOIN慢数倍
PostgreSQL 中用 DISTINCT ON 更简洁
这是 PostgreSQL 特有语法，语义明确：对指定字段去重，保留每个分组中 ORDER BY 第一条。
- 写法比窗口函数短：
SELECT DISTINCT ON (user_id) * FROM orders ORDER BY user_id, created_at DESC, id DESC - 必须把
DISTINCT ON字段放在ORDER BY最前面，否则报错 - 不支持 MySQL 或 SQL Server，跨数据库迁移时得重写
实际选哪种方式，取决于你用的数据库版本、是否要跨库兼容、以及“最新”的定义到底依赖时间戳还是主键——这几个点没理清，再漂亮的 SQL 也快照不准。
