ROW_NUMBER()能解决积压重复问题，因其可按业务主键分组、依数据质量排序（如event_time DESC），取每组首行实现“留最新/最全、删冗余”。
ROW_NUMBER() 为什么能解决积压导致的重复问题
数据积压时，上游常会重发或补传一批记录（比如 Kafka 消费滞后后触发重投），导致下游表里出现多条逻辑上相同的行。单纯用 DISTINCT 或 GROUP BY 往往不够——因为时间戳、批次号等字段可能不同，但业务主键（如 order_id + event_time）才真正决定“是否为同一事件”。ROW_NUMBER() 能按业务主键分组、按可信度排序（比如用更新的时间戳、更完整的日志字段），只取每组第一条，本质是“留最新/最全，删冗余”。
怎么写一个安全的 ROW_NUMBER() 去重语句
关键不是套函数，而是控制好分区和排序逻辑。错误写法是直接 ROW_NUMBER() OVER (PARTITION BY id ORDER BY id)——这没意义，排序字段和分区字段一样，结果不可控。
- 分区字段必须是业务上定义“重复”的依据，比如
PARTITION BY order_id, user_id - 排序字段要反映数据质量优劣：优先选
event_time DESC（新事件覆盖旧事件），其次加log_version DESC或ingest_timestamp DESC防止时间相同 - 务必加上
WHERE rn = 1过滤，不能只靠SELECT *后人工筛
示例（PostgreSQL / MySQL 8.0+）：
SELECT * FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY order_id, user_id
ORDER BY event_time DESC, log_version DESC, ingest_timestamp DESC
) AS rn
FROM raw_events
) t WHERE rn = 1;常见踩坑：ORDER BY 字段为空 or 类型不一致
积压数据里经常有 NULL 的 event_time，或者字符串格式混入（如 '2024-01-01' 和 '2024/01/01'）。这时 ORDER BY event_time DESC 会让 NULL 排最前（SQL 标准中 NULLS FIRST 是默认），导致反向选中脏数据。
- 显式控制 NULL 位置：
ORDER BY event_time DESC NULLS LAST（PostgreSQL） - MySQL 不支持
NULLS LAST，改用ORDER BY IFNULL(event_time, '1970-01-01') DESC - 字符串时间先转类型再排：
ORDER BY CAST(event_time AS TIMESTAMP) DESC，但要注意转换失败报错，生产环境建议提前清洗 - 如果排序字段类型不统一（比如整数和字符串混存版本号），
log_version DESC可能按字典序排错（'10' ），应转成整数：<code>CAST(log_version AS INTEGER)
去重后还要注意主键冲突和物化成本
用 ROW_NUMBER() 结果直接 INSERT INTO target_table 很危险——目标表如果有唯一约束（如 UNIQUE(order_id)），而你选中的“最新”行其实仍是旧数据（比如积压期间上游修复了 bug，但补发的数据还没进库），就会插入失败或覆盖出错。
- 上线前确认目标表是否有唯一索引；如有，建议先
DELETE再INSERT，或改用MERGE/UPSERT -
ROW_NUMBER()在大数据量下性能敏感：分区键选择不当（如用高基数字段）会导致 shuffle 过重；排序字段无索引时，数据库可能走全表扫描 - 临时表或 CTE 中嵌套太深（比如多层
WITH套用ROW_NUMBER()）容易让优化器误判，建议拆成中间物化步骤，尤其在 Hive/Spark SQL 中
真正难的不是写出那行 ROW_NUMBER()，而是搞清哪几个字段组合才算“一次有效事件”，以及当它们互相矛盾时，你信谁。
