用 row_number() 按组内时间倒序标号可精准取每组最新一条记录，避免 rank()/dense_rank() 因并列时间导致多返回、不可控等问题，且比 group by + max() 关联更可靠；需注意 null 处理、分区键一致性及排序稳定性。
用 ROW_NUMBER() 按组内时间倒序标号
核心思路是给每组数据按 created_at（或你的时间字段）降序排个名，取名次为 1 的那条。这比 GROUP BY + MAX() 再关联回原表更直接、也更可靠——后者在有并列最晚时间时可能漏数据。
实操建议：
- 确保时间字段不为空，否则
NULL会被排到最后（ORDER BY xxx DESC默认把NULL当最小值），导致标号错乱；可加WHERE created_at IS NOT NULL过滤 - 分区键（
PARTITION BY）必须和业务分组逻辑一致，比如按user_id分组就写PARTITION BY user_id，别漏掉复合条件如PARTITION BY tenant_id, user_id - 排序用
ORDER BY created_at DESC，如果时间精度到秒但存在微秒级差异，建议显式补上, id DESC防止窗口函数随机选行（尤其 PostgreSQL / MySQL 8.0+）
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;
RANK() 和 DENSE_RANK() 什么时候不能替代 ROW_NUMBER()
当同一组里有多条记录时间完全相同时，RANK() 会把它们全标为 1，接着跳到 3；DENSE_RANK() 也是全标 1，接着标 2。如果你只要一条“最晚记录”，这两种函数会导致结果多于预期——尤其是做 UPDATE 或 INSERT SELECT 时容易重复写入。
常见错误现象：
- 本想每用户取一条最新订单，结果某用户有两条同秒创建的订单，
RANK()返回了两条，下游逻辑崩了 - 用
DENSE_RANK()后接WHERE dr = 1，看似没问题，但实际无法控制哪条被保留，不同执行计划下结果不一致 - Oracle 中
RANK()对NULL的处理和ROW_NUMBER()不同，混用易出错
MySQL 5.7 或旧版 PostgreSQL 怎么办
这些版本不支持窗口函数，硬上 ROW_NUMBER() 会报错 FUNCTION xxx does not exist 或直接语法失败。得换策略，但别用相关子查询（WHERE time = (SELECT MAX(...) FROM ...)），它在大数据量下极慢，且仍无法解决并列时间问题。
实操建议：
- MySQL 5.7：用自连接 + 左外连接找“不存在更新时间的同组记录”，即
LEFT JOIN orders o2 ON o1.user_id = o2.user_id AND o1.created_at - PostgreSQL 9.5 以下：可用
NOT EXISTS替代，语义更清晰，性能也相对可控 - 所有旧版本都建议给
(user_id, created_at)加联合索引，否则上述方案全表扫描开销巨大
为什么不能只靠 GROUP BY + MAX(created_at)
因为 SELECT user_id, MAX(created_at) FROM orders GROUP BY user_id 只能拿到时间和分组字段，其他字段（比如 order_status、amount）根本不确定来自哪一行——MySQL 5.7 默认允许这种“非确定性聚合”，但返回值是随机的；MySQL 8.0+ 或 PostgreSQL 开 strict mode 后直接报错 ERROR 1055。
典型翻车场景：
- 查“每个用户最新订单金额”，结果金额对不上那个最晚时间点的订单，而是某条更早订单的金额
- 在报表中展示最新订单状态，却显示成该用户第一条订单的状态
- 导出数据后被业务方质疑：“这笔订单明明已取消，怎么显示‘待支付’？”
窗口函数不是银弹，但它把“先分组、再排序、再取首行”这个逻辑锁死在一层查询里，避免了多层嵌套和不确定性。真正麻烦的是时间字段类型不统一（TIMESTAMP vs DATETIME vs 字符串）、时区没对齐、或者历史数据里混着 '0000-00-00' 这种非法值——这些细节不处理，窗口函数照样给你返回意料之外的结果。
