MySQL 8.0 窗口函数 ROW_NUMBER() 去重：保留最新订单，先查再删

订单导入脚本重跑了一次，order_no 相同的记录多出了几行。这个时候直接按时间删风险很高：同一时间戳可能存了多条记录，只有主键才是完全不会重复的最终删除边界。MySQL 8.0 提供的 ROW_NUMBER() 可以先按业务唯一键分组，再按写入时间和主键排序，哪行留哪行删，结果算得明明白白。

先用窗口函数生成重复组的序号，再把序号大于 1 的主键放进临时表；确认数量、样本和备份都正确后，才执行 DELETE。

先确定重复记录的业务边界

示例表 shop_orders 中，shop_id 和 order_no 组合代表一笔店铺维度的订单，id 是自增主键，created_at 是数据写入数据库的时间。我们的清理目标很明确：同一店铺、同一订单号只保留最晚写入的那一行。

CREATE TABLE shop_orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  shop_id BIGINT NOT NULL,
  order_no VARCHAR(40) NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  order_status VARCHAR(20) NOT NULL,
  created_at DATETIME(6) NOT NULL,
  KEY idx_shop_order_time (shop_id, order_no, created_at)
);

SELECT shop_id, order_no, COUNT(*) AS duplicate_count
FROM shop_orders
GROUP BY shop_id, order_no
HAVING COUNT(*) > 1;

这一步只做问题范围确认。如果业务本身允许同一个订单号在不同店铺重复，shop_id 就不能省略；如果表里存的是订单状态快照而非重复写入的脏数据，清理规则也要调整成保留每个状态的最后一条记录。

用 ROW_NUMBER() 给每个重复组排号

窗口函数不会改动原表数据，只会在查询结果里额外生成一列序号。下面的 PARTITION BY 用来定义重复分组，ORDER BY created_at DESC, id DESC 用来指定最新写入的记录排最前面；当两条记录写入时间完全相同时，数值更大的主键排在前面。

WITH ranked_orders AS (
  SELECT
    id,
    shop_id,
    order_no,
    amount,
    order_status,
    created_at,
    ROW_NUMBER() OVER (
      PARTITION BY shop_id, order_no
      ORDER BY created_at DESC, id DESC
    ) AS row_num
  FROM shop_orders
)
SELECT *
FROM ranked_orders
WHERE row_num > 1
ORDER BY shop_id, order_no, row_num;

结果里序号等于 1 的 row_num = 1 就是需要保留的行，其余序号大于1的行都是待删候选。这步先别着急执行删除操作，至少抽查几个样本的订单金额、状态和写入时间；如果发现同一订单的最新行反而是失败状态，说明“按最新写入保留”的规则不符合业务需求，要把状态优先级加到排序逻辑里。

先保存待删主键，再执行可核对的删除

为了避免同一段窗口查询在删除前后得到不一致的结果，先建一张临时表把候选删除的主键全部存下来。临时表仅在当前数据库连接中可见，适合单次清理任务；如果需要人工跨连接复核或者做回滚留痕，应该用带清理批次号的永久备份表。

CREATE TEMPORARY TABLE dedup_delete_ids (
  id BIGINT PRIMARY KEY
);

INSERT INTO dedup_delete_ids (id)
WITH ranked_orders AS (
  SELECT
    id,
    ROW_NUMBER() OVER (
      PARTITION BY shop_id, order_no
      ORDER BY created_at DESC, id DESC
    ) AS row_num
  FROM shop_orders
)
SELECT id
FROM ranked_orders
WHERE row_num > 1;

SELECT COUNT(*) AS delete_count
FROM dedup_delete_ids;

SELECT o.*
FROM shop_orders AS o
JOIN dedup_delete_ids AS d ON d.id = o.id
ORDER BY o.shop_id, o.order_no, o.created_at;

核对完总数量和抽样样本都没问题之后，再在事务里按主键条件删除。删除后先检查实际影响行数，再决定提交还是回滚；不要把临时表里的ID重新关联业务字段匹配删除，不然很容易误删刚写入的新记录。

START TRANSACTION;

DELETE o
FROM shop_orders AS o
JOIN dedup_delete_ids AS d ON d.id = o.id;

SELECT ROW_COUNT() AS affected_rows;

-- 核对 affected_rows 与 delete_count 一致后再提交
COMMIT;
-- 发现数量或样本不对时使用：ROLLBACK;

三个检查点决定能不能提交

SELECT shop_id, order_no, COUNT(*) AS remaining_count
FROM shop_orders
GROUP BY shop_id, order_no
HAVING COUNT(*) > 1;

大表清理不要一次锁住全部重复行

几万行以内的小重复数据集，可以在业务低峰时段一次性处理完；如果是大表并且线上写入还在持续进行，建议按 id 的范围拆分批次处理，每一批次都单独记录候选行数和实际影响行数。批次之间留少量间隔，让锁等待和主从复制延迟有时间恢复。

如果删除操作需要留长期审计痕迹，先把待删记录写入归档表，至少要保存原主键、业务键、原始状态字段、清理批次号和操作人信息。临时表只适合快速临时任务，不能代替正式的长期数据归档留痕。

常见问题

ROW_NUMBER() 和 RANK() 做去重该选哪个？

删除重复行的场景基本都选 ROW_NUMBER()，它会给每一行分配完全唯一的序号；RANK() 遇到完全相同的排序值会生成并列名次，最后会导致多条重复行都被保留。

为什么 ORDER BY 排序条件里还要加主键 id？

如果只按时间排序，当时间精度不足或者批量导入时多条记录写入时间完全相同，最终生成的排序结果就会不稳定。把主键作为最后一级排序键，可以保证每次查询得到的待删候选集合完全一致。

能不能直接把 DELETE 语句套在窗口函数子查询里执行？

语法上支持写子查询，但窗口计算出来的待删结果最好先落到临时表或者备份表里，方便核对数量、保留回滚的完整证据。这种复杂删除操作落到实表后，也更容易发现并发写入带来的数据偏差。

清理完重复数据之后要不要立刻加唯一索引？

如果这些业务键本来就应该是全局唯一的，可以在确认历史数据和上游写入流程都满足约束条件之后再加；没清完残留脏数据就直接加唯一索引，很容易因为冲突直接失败，线上结构变更也要单独评估影响范围。

把“先查再删”固定成清理流程

这类数据去重的核心不是靠某条特殊SQL搞定，而是把业务去重键、保留规则、候选主键清单、实际影响行数和唯一性复查串成一条完整的证据链。后续再遇到导入重跑、接口重试造成的重复数据，先把查询结果拉出来人工审阅一遍，再开事务执行删除，风险会比直接按时间条件盲清理小很多。