核心思路是用row_number()配合partition by order_id和order by created_at desc为每组订单按时间倒序编号,取rn=1的最新记录;必须用cte或子查询生成序号,不可在where中直接使用,且建议添加id等唯一字段兜底确保排序稳定。

用 ROW_NUMBER() 给订单按时间排序并标记序号
核心思路是:把同一订单号的多条记录按时间(比如 created_at)倒序排,最新的一条标为 1,再用外层查询只取 rn = 1 的行。注意必须用 ORDER BY 明确指定排序依据,否则 ROW_NUMBER() 的结果不可预测。
常见错误是直接在 WHERE 中用 ROW_NUMBER() —— 它不能出现在 WHERE 子句里,必须先放在子查询或 CTE 中生成序号列。
-
PARTITION BY order_id是关键:确保每个订单号内部独立编号 - 排序方向很重要:
ORDER BY created_at DESC才能保证最新记录得1;若用ASC,反而会保留最老的那条 - 如果存在毫秒级时间戳但业务上认为“同秒即重复”,建议先用
DATE_TRUNC('second', created_at)或CAST(created_at AS TIMESTAMP(0))统一精度,再排序
CTE 方式写法最清晰、易调试
相比嵌套子查询,CTE 更易读且支持多次引用。调试时可先运行 CTE 部分,确认 rn 列是否符合预期。
WITH ranked_orders AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY order_id
ORDER BY created_at DESC, id DESC
) AS rn
FROM orders
)
SELECT * FROM ranked_orders WHERE rn = 1;
这里加了 id DESC 作为第二排序条件,是为了在 created_at 完全相同时,稳定地选中最大 id 的那条(通常对应最后插入的记录)。不加这个可能导致相同时间下结果不稳定。
WHERE 条件要放在 CTE 外层还是内层?
性能和语义都要求:过滤条件尽量下推到 CTE 内部。比如只查「近 30 天」的去重订单,应该写在 CTE 的 FROM 子句后,而不是外层 SELECT 后。
- ✅ 正确(先缩小数据集,再分区编号):
FROM orders WHERE created_at >= NOW() - INTERVAL '30 days' - ❌ 低效(全表编号后再过滤):
外层加AND created_at >= ...,会导致无谓的大量ROW_NUMBER()计算 - 如果过滤字段不在
PARTITION BY或ORDER BY中,下推不影响逻辑正确性,但能显著减少内存和 CPU 开销
ORDER BY 中用了表达式或函数会影响性能
比如写成 ORDER BY DATE(created_at) 或 ORDER BY UPPER(customer_name),会让数据库无法使用索引加速排序,尤其在大表上可能触发磁盘临时文件。
更稳妥的做法是:提前建好函数索引(如 PostgreSQL 的 CREATE INDEX ON orders ((DATE(created_at)))),或在应用层/ETL 中预计算好归一化字段存为新列(如 order_date),然后直接按该列排序。
另外,ROW_NUMBER() 是窗口函数,不支持在 GROUP BY 查询中直接混用——想同时聚合(如统计每个订单的总金额)又去重,得用两层嵌套或先去重再聚合。











