row_number()是获取每组最新记录最可靠方法，需在子查询中用partition by分组、order by时间desc加唯一字段二级排序，再where rn=1过滤；不可在where中直接引用窗口函数。
用 ROW_NUMBER() 按时间排序取最新，但不丢重复值
窗口函数本身不“删除”数据，它只生成序号或聚合结果。所谓“保留最新记录”，本质是：对每组重复键（如 user_id），按时间字段（如 updated_at）降序排，取序号为 1 的那行。关键在于——ROW_NUMBER() 会强制给相同时间戳的记录分配不同序号，而 RANK() 或 DENSE_RANK() 则不会，这直接影响是否“保留所有最新”。
实操建议：
- 优先用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC, id DESC)—— 加id DESC是为打破时间相同时的不确定性，确保结果可复现 - 避免只写
ORDER BY updated_at DESC：若多条记录时间完全相同，ROW_NUMBER()分配顺序由数据库执行计划决定，每次查询可能不同 - 如果业务允许“多个并列最新”（比如同秒更新的都算最新），改用
RANK()；但注意它会产生重复序号，后续WHERE rn = 1会保留全部并列项
WHERE 子句过滤必须在窗口计算之后
窗口函数不能出现在 WHERE 或 GROUP BY 中，这是常见报错根源。你不能写 WHERE ROW_NUMBER() = 1，SQL 会直接报错 invalid window function reference。
正确做法只有两种：
- 用子查询或 CTE 先算出序号，再在外层
WHERE rn = 1 - 用
QUALIFY（仅支持 BigQuery、Snowflake、DuckDB 等）——例如SELECT * FROM t QUALIFY ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) = 1 - PostgreSQL/MySQL 8.0+ 必须套一层：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC, id DESC) AS rn FROM orders ) t WHERE rn = 1
重复键定义不清会导致“最新”逻辑失效
“重复数据”指什么？是 user_id 相同？还是 user_id + product_id 组合相同？这个业务语义必须明确，否则窗口分区写错，结果全偏。
典型陷阱：
- 把
PARTITION BY user_id写成PARTITION BY user_id, status：如果只想按用户取最新，加了status就变成“每个状态下的最新”，不是你要的 - 忽略 NULL 值影响：
PARTITION BY字段含 NULL 时，多数数据库把所有 NULL 归为同一组——若user_id允许为空，这一组会混杂多个“未知用户”的最新记录，极易误判 - 时间字段类型不一致：比如用
created_date（DATE 类型）代替created_at（TIMESTAMP），丢失时分秒精度，导致本应区分的记录被当作“同时间”处理
性能隐患：大表慎用未索引的 PARTITION BY 字段
窗口函数在底层通常需要对分区字段排序或哈希分组。如果 PARTITION BY 字段没索引，且数据量上千万，ROW_NUMBER() 可能触发磁盘临时排序，查询从秒级变分钟级。
优化要点：
- 确保
PARTITION BY字段（如user_id）和ORDER BY字段（如updated_at）联合有索引，例如：CREATE INDEX idx_user_updated ON table_name (user_id, updated_at DESC) - MySQL 8.0 对窗口函数的优化较弱，同等条件下 PostgreSQL 或 ClickHouse 执行更稳
- 如果只是偶尔查最新，且表更新频繁，考虑物化最新记录到单独小表，比每次跑窗口更可靠
真正难的不是写对那行 ROW_NUMBER()，而是确认“重复”按什么粒度定义、时间字段有没有精度陷阱、以及数据库是否真能扛住那个 PARTITION BY。
