用ROW_NUMBER()按时间戳去重最稳，核心是PARTITION BY指定重复判定字段、ORDER BY timestamp DESC确保取最新行；漏写或误用ASC会导致结果不可控，且需注意NULL值、时间精度及数据库语法差异。
用 ROW_NUMBER() 按时间戳去重，核心是窗口函数的排序和分区逻辑
直接结论：想保留每组重复记录中最新（或最旧）的一条，必须用 ROW_NUMBER() 配合 OVER (PARTITION BY ... ORDER BY timestamp DESC)。不写 ORDER BY 或顺序错，结果就不可控——数据库不会“默认按时间选最新”，它只按你写的排序来编号。
常见错误现象：ROW_NUMBER() 编号乱序、同一批重复数据里删掉了新记录、甚至不同数据库（如 MySQL 8.0 vs PostgreSQL）行为不一致，往往就是 ORDER BY 漏了或用了 ASC 却想要最新数据。
-
PARTITION BY列要严格对应你定义的“重复”逻辑（比如user_id, order_id，不是只写user_id） - 时间戳字段必须 非 NULL；如果存在
NULL，ORDER BY timestamp DESC会把它们排在最前（多数数据库行为），导致ROW_NUMBER() = 1误选NULL记录 - 若时间精度到秒但存在并发写入，可能多个记录时间戳完全相同——此时仅靠
timestamp排序无法保证稳定顺序，建议补上主键或自增 ID：ORDER BY timestamp DESC, id DESC
DELETE 重复行时，不能直接在原表上用 ROW_NUMBER()
绝大多数 SQL 引擎（包括 PostgreSQL、SQL Server、MySQL 8.0+）不支持在 DELETE 语句中直接嵌套带窗口函数的子查询。硬写会报类似 ERROR: window functions are not allowed in DELETE 的错误。
正确做法是先用 CTE 或子查询生成带序号的结果，再关联原表删除：
WITH ranked AS (
SELECT id,
ROW_NUMBER() OVER (
PARTITION BY user_id, email
ORDER BY updated_at DESC, id DESC
) AS rn
FROM users
)
DELETE FROM users
USING ranked
WHERE users.id = ranked.id AND ranked.rn > 1;
注意点：
- PostgreSQL 用
DELETE ... USING；MySQL 8.0+ 要改用JOIN写法，且必须给原表起别名 - 别漏掉
WHERE rn > 1—— 否则删的是最新那条 - 操作前务必备份或在事务里测试：
BEGIN; ... ROLLBACK;
时间戳字段类型影响排序稳定性
TIMESTAMP 和 DATETIME 在不同数据库中默认精度不同：MySQL 5.6 的 DATETIME 只到秒，PostgreSQL 的 TIMESTAMP 默认微秒级。如果业务要求精确到毫秒去重，而字段实际只存到秒，那所有该秒内的记录都会被视作“时间相同”，ROW_NUMBER() 的排序就退化为无序。
检查方式：
- PostgreSQL：
\d table_name看字段类型是否为TIMESTAMP(3)（毫秒） - MySQL：
SHOW COLUMNS FROM table_name LIKE 'updated_at';看Type是否含(3) - 如果字段没带精度，又确实存在高频写入，建议显式修改字段：
ALTER TABLE logs ALTER COLUMN created_at TYPE TIMESTAMP(3);（PG）或MODIFY created_at DATETIME(3)（MySQL）
替代方案：用 GROUP BY + MAX() 更简单？
能不用窗口函数就不用，前提是你的需求只是“取每组最新时间值”，而不是“取整行最新记录”。SELECT user_id, MAX(updated_at) FROM t GROUP BY user_id 是安全的，但它只返回两列——如果你还要 email、status 等其他字段，就必须加 JOIN 回原表，而这时一旦有多个记录共享同一最大时间，就会产生多对一膨胀，结果反而比用 ROW_NUMBER() 更难控制。
所以真正要删重复行或取完整最新记录时，ROW_NUMBER() 不是“高级技巧”，而是必要手段。容易被忽略的点在于：它依赖的排序字段是否真能唯一确定先后，以及执行环境是否允许你在目标语句中直接使用窗口函数。
