直接结论：用 ROW_NUMBER() 配合 PARTITION BY 和 ORDER BY 时间字段（如 created_at DESC）取序号为 1 的行，可精准获取每组最新记录；关键需确保排序字段组合唯一（如加 id DESC 兜底），避免因时间重复或 NULL 导致结果不确定，且优先于聚合 + JOIN 方案。
用 ROW_NUMBER() 配合 PARTITION BY 拿最新一条
直接结论：靠 ROW_NUMBER() 按时间倒序排序，再筛出序号为 1 的行。这不是“查最新”，而是“按指定字段排后取第一”，所以关键在排序依据是否真能反映“最新”——比如用 created_at 或 id（自增主键），别用模糊的 updated_at（可能被反复更新）。
常见错误是写成 ORDER BY updated_at DESC 却没考虑并发更新导致的时间重复，结果 ROW_NUMBER() 分配顺序不确定，同时间戳的记录每次执行可能选不同行。
- 必须确保排序字段组合能唯一确定一行，例如
ORDER BY created_at DESC, id DESC - 如果只有
updated_at，且业务上允许“任意一条最新”，那就加个id DESC做次级排序兜底 -
PARTITION BY的列要和业务分组逻辑一致，比如按user_id查每人最新订单，就写PARTITION BY user_id
为什么不能用 MAX() + JOIN？
很多人想先用 GROUP BY 拿每组最大时间，再连回原表匹配。这看似合理，但实际会漏数据或错配——因为 MAX(created_at) 只能告诉你时间，不能保证该时间对应哪一行的其他字段（比如 status 或 amount），尤其当多行共享同一时间戳时，JOIN 可能命中多行或非预期行。
窗口函数天然绑定整行，不存在字段错位问题。而聚合 + JOIN 方案需要额外去重逻辑（如 ROW_NUMBER() 或 DISTINCT ON），反而绕远路。
- MySQL 8.0+、PostgreSQL、SQL Server 都支持标准窗口函数，优先用
ROW_NUMBER() - 旧版 MySQL（5.7）不支持窗口函数，才需退化为相关子查询或变量模拟，但性能差、难维护
- SQLite 3.25+ 支持，但注意其
ORDER BY在窗口定义中不支持表达式，只能用列名
ORDER BY 中 NULL 怎么处理？
如果排序字段含 NULL（比如部分记录还没设置 created_at），默认 NULLS FIRST 还是 NULLS LAST 因数据库而异：PostgreSQL 默认 NULLS LAST，MySQL 和 SQL Server 把 NULL 当最小值（即排最前）。这意味着 ORDER BY created_at DESC 可能把 NULL 排在顶部，导致 ROW_NUMBER() = 1 选出空时间的脏数据。
- 显式写
ORDER BY created_at DESC NULLS LAST（PostgreSQL/Oracle 支持） - MySQL/SQL Server 用
ORDER BY created_at IS NULL, created_at DESC把NULL排最后 - 更稳妥的做法是过滤掉
created_at IS NULL再开窗，避免歧义
性能要注意什么？
窗口函数本身不索引友好，ROW_NUMBER() 必须扫描并排序整个分区。如果分组键基数高（比如百万用户），或排序字段没索引，查询会明显变慢。
- 确保
PARTITION BY列 +ORDER BY列有联合索引，例如(user_id, created_at DESC) - 避免在窗口函数外再套一层
WHERE过滤“最新记录”，应该先过滤再开窗（比如先WHERE status = 'active'，再对结果开窗） - 大数据量时，考虑物化最新记录视图，或用应用层缓存代替实时计算
真正麻烦的不是语法，而是“最新”的定义是否和业务一致——比如财务系统里“最新”可能是审批通过时间，而不是创建时间；日志系统里可能要按事件发生时间而非入库时间。窗口函数只是工具，输入错了，输出再准也没用。
