ROW_NUMBER() 必须配合 PARTITION BY timestamp 和 ORDER BY（如id）才能精准识别并删除重复时间戳行，漏掉PARTITION BY会导致误删；需统一时间戳精度、用CTE或子查询封装、事务验证后再执行。
ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 才能区分重复时间戳
只写 ROW_NUMBER() OVER() 会为全表行生成连续序号，无法识别“相同时间戳内的重复”。关键是要用 PARTITION BY timestamp 把同时间戳的记录归为一组，再用 ORDER BY 决定组内保留哪一条——比如按主键、ID 或业务字段（如 ORDER BY id ASC 保留最早插入的）。
常见错误是漏掉 PARTITION BY，结果删掉的不是重复行，而是前 N 行；或者 ORDER BY 用了不可靠字段（如无索引的字符串列），导致排序不稳定，删错数据。
- 确保
timestamp列类型一致（避免DATETIME和TIMESTAMP混用，时区或精度差异可能让本该相等的时间被视作不同） - 如果时间戳带毫秒但数据库只存到秒（如 MySQL 5.6 默认），需先统一截断或补零，否则
PARTITION BY分不到一组 - 测试时先用
SELECT查出要删的行：SELECT id, timestamp, ROW_NUMBER() OVER (PARTITION BY timestamp ORDER BY id) AS rn FROM orders;
DELETE 需用 CTE 或子查询套一层，不能直接在 FROM 中用窗口函数
绝大多数 SQL 引擎（PostgreSQL、SQL Server、MySQL 8.0+）不支持 DELETE FROM ... WHERE ... IN (SELECT ROW_NUMBER() ...) 这类直接嵌套窗口函数的写法。必须把带 ROW_NUMBER() 的查询封装成 CTE 或派生表，再对它做删除。
例如 PostgreSQL/SQL Server 正确写法：
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (PARTITION BY timestamp ORDER BY id) AS rn FROM orders ) DELETE FROM orders USING ranked WHERE orders.id = ranked.id AND ranked.rn > 1;
MySQL 8.0+ 只能用子查询（CTE 在 DELETE 中受限）：
DELETE o1 FROM orders o1 INNER JOIN orders o2 ON o1.timestamp = o2.timestamp AND o1.id > o2.id;
注意：这个 JOIN 写法虽不用窗口函数，但性能差、易锁表，且要求 id 严格反映插入顺序——不如 CTE + ROW_NUMBER() 精准可控。
时间戳精度问题常导致“看似重复实则不同”，务必先验证
执行删除前，先查出高频时间戳及其实际分布：
SELECT timestamp, COUNT(*) c FROM orders GROUP BY timestamp HAVING c > 1 ORDER BY c DESC LIMIT 5;
如果返回的 timestamp 值看起来一样，但删不掉重复，大概率是精度藏雷：
- PostgreSQL 的
TIMESTAMP WITHOUT TIME ZONE可能存了微秒，但SELECT默认只显示到毫秒 - MySQL 的
DATETIME(3)和DATETIME(6)长度不同，PARTITION BY会严格按存储值分组 - 解决办法：统一 cast 成固定精度，例如
PARTITION BY DATE_FORMAT(timestamp, '%Y-%m-%d %H:%i:%s')（MySQL）或PARTITION BY (timestamp :: TIMESTAMP(0))（PostgreSQL）
生产环境删重必须加事务 + 限流 + 备份检查
哪怕语句逻辑正确，一次性删几千行也可能锁表或触发慢日志告警。更危险的是误删——比如 PARTITION BY 条件写错，把全天数据当一组删掉。
- 始终用
BEGIN; ... DELETE ...; SELECT ROW_COUNT(); ROLLBACK;先试跑，确认行数符合预期再COMMIT - 大表建议分批删：加上
AND id BETWEEN ? AND ?或用LIMIT（MySQL） /TOP N（SQL Server）控制每次删 1000 行 - 删前用
CREATE TABLE orders_backup AS SELECT * FROM orders WHERE timestamp IN (...);快速备份可疑时间段数据
最易忽略的是：没检查业务是否允许“按时间戳去重”。有些场景下，同一秒内多笔订单是合法的（如秒杀），删掉反而引发对账不平。
