核心思路是用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 查询中直接混用——想同时聚合（如统计每个订单的总金额）又去重，得用两层嵌套或先去重再聚合。
