row_number()必须配合partition by分组和order by排序才能取每组最新记录；单独使用仅对全表编号，无法分组；where rn=1须在子查询或cte中执行，不可直接过滤。

ROW_NUMBER() 必须配合 PARTITION BY 才能分组编号

直接写 ROW_NUMBER() 不加 PARTITION BY 会把整张表当成一个组连续编号，根本达不到“每组取最新”的效果。关键在于用 PARTITION BY 指定分组字段（比如用户ID、订单类别），再用 ORDER BY 控制组内排序逻辑——通常按时间戳倒序，这样最新记录排在第1位。

常见错误是只写 ORDER BY create_time DESC 却漏掉 PARTITION BY user_id，结果所有记录被编成一串递增序号，后续过滤 rn = 1 只能拿到全局第一条。

• 分组字段必须是业务上明确的聚合维度，比如 user_id、product_type
• ORDER BY 里建议包含唯一键（如 id）防并列，避免同秒插入时排序不稳定
• 如果时间字段可能为 NULL，记得加 NULLS LAST（PostgreSQL）或用 IS NULL 显式处理（MySQL 8.0+）

WHERE 子句不能直接过滤窗口函数结果

ROW_NUMBER() 是窗口函数，生成的是计算列，不能在同一个查询层级用 WHERE rn = 1 过滤——SQL 执行顺序决定 WHERE 先于窗口函数执行，此时 rn 还不存在。

必须用子查询或 CTE 提前算出序号，再在外层筛选。这是新手最常卡住的地方，报错通常是 Unknown column 'rn' in 'where clause' 或类似提示。

• 推荐用 CTE：先 WITH ranked AS (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM ...)，再 SELECT * FROM ranked WHERE rn = 1
• 子查询也行，但嵌套过深可读性差，尤其多层窗口时容易混乱
• 别试图用 HAVING 替代——HAVING 针对 GROUP BY 聚合结果，和窗口函数无关

ORDER BY 时间字段要注意时区和精度

用 create_time 或 update_time 排序时，如果数据库时区和应用不一致，或者字段精度是秒级（多个操作落在同一秒），ROW_NUMBER() 可能随机分配序号，导致“最新”结果不可靠。

• 优先用带毫秒/微秒的字段，比如 created_at 类型为 TIMESTAMP(6)
• MySQL 中 DATETIME 默认无毫秒，需定义为 DATETIME(3)；PostgreSQL 的 TIMESTAMP WITH TIME ZONE 更稳妥
• 如果只有秒级时间，强制加入主键 ORDER BY create_time DESC, id DESC 确保唯一排序

替代方案：RANK() 和 DENSE_RANK() 不适合“取一条”场景

有人误以为 RANK() 或 DENSE_RANK() 更直观，但它们对相同排序值会赋予相同排名（比如两条记录时间完全一样，都得 1），后续 WHERE rn = 1 可能返回多条，违背“取最新一条”的原始需求。

ROW_NUMBER() 是唯一能保证每行获得不同序号的窗口函数，哪怕排序依据完全相同，也会按物理顺序或优化器决定的顺序严格编号。

• 除非业务明确允许并列（比如“取所有并列最新的记录”），否则必须用 ROW_NUMBER()
• MySQL 8.0+ 和 PostgreSQL 支持 QUALIFY（Snowflake/BigQuery 语法），但主流关系库仍需 CTE 或子查询

实际执行时最容易忽略的是排序字段的确定性和唯一性——时间字段看着可靠，但高并发写入下秒级精度就是隐患，加主键兜底不是过度设计，是防止线上数据错乱的底线。