SQL如何批量处理重复数据？DELETE与GROUP BY组合清理
DELETE 不能直接跟 GROUP BY，这是最常踩的语法坑
如果你尝试执行 DELETE FROM table GROUP BY column，结果只会是报错。无论是 MySQL 还是 PostgreSQL，都不支持这种写法。原因很简单：GROUP BY 是聚合语义，它把数据打包成组；而 DELETE 操作需要精准定位到具体的行。强行套用，MySQL 会抛出 ERROR 1093，PostgreSQL 则会提示 ERROR 42601，核心意思都是“语法错误”或“不能在子查询中修改目标表”。
那么，正确的路怎么走？其实核心思路就两条：
- 先用子查询找出每组里要保留的主键（比如最小的
id），然后用NOT IN或NOT EXISTS反向筛选出要删除的行。 - 借助 CTE 和窗口函数（比如
ROW_NUMBER()），在逻辑层给重复数据打上序号标记，然后精准删除那些序号大于1的行。
用子查询 + NOT IN 保留最小 ID 的重复记录
这个方法兼容性最好，适用于 MySQL 5.7、SQLite 或 SQL Server 等一些还不支持窗口函数的数据库版本。它的核心逻辑是：先按照业务字段（比如邮箱）分组，选出每组中主键最小（通常是最早插入）的那条记录，然后删除所有不在这个“保留名单”里的行。
来看一个具体例子（按 email 字段去重，保留最早插入的记录）：
DELETE FROM users WHERE id NOT IN ( SELECT MIN(id) FROM users GROUP BY email );
这里有三个关键细节需要注意：
- 那个
SELECT MIN(id)子查询，通常需要被包裹一层。比如在 MySQL 里，派生表必须有个别名，简单加个AS t就行。 - 如果
email字段允许为 NULL，那么GROUP BY email会把所有 NULL 值归为一组，最终只保留一条 NULL 记录。这很可能不是你想要的结果，建议提前用WHERE email IS NOT NULL过滤一下。 - 在大表上操作前，务必为分组字段建立索引，例如
CREATE INDEX idx_email ON users(email);。否则，GROUP BY会引发全表扫描，性能堪忧。
用 CTE + ROW_NUMBER() 精确控制保留哪条重复数据
如果你的数据库是 MySQL 8.0+、PostgreSQL、SQL Server 或 Oracle，那么恭喜你，可以使用更强大的方法。它的优势在于，你可以根据业务需求（比如时间、状态、权重）来排序，而不仅仅是依赖主键的大小。
示例：按 email 分组，但保留 created_at 时间最新的那条记录。
WITH ranked AS (
SELECT id, email, created_at,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at DESC) AS rn
FROM users
)
DELETE FROM users WHERE id IN (SELECT id FROM ranked WHERE rn > 1);
这里面的门道是：
ORDER BY created_at DESC决定了把最新时间排第一（rn=1）。如果想保留最早的，换成ASC即可。- 如果需要根据多个字段组合来判断重复，直接在
PARTITION BY后面加上就行，比如PARTITION BY email, status。 - 需要注意，某些数据库（如 MySQL）的语法检查器可能不允许在同一个语句中直接删除 CTE 引用的表。这时，稳妥的做法是拆成两步：先用 CTE 或临时表存储需要删除的
id列表，再执行删除。
物理删除前必须做的三件事
批量删除重复数据可不是 SELECT 查询，能随便执行看看结果。这是一条“不归路”，尤其在表存在外键约束、触发器，或者正被应用程序频繁读写时，风险极高。动手前，这三件事一个都不能少：
- 先备份：最稳妥的方式是用
CREATE TABLE users_backup AS SELECT * FROM users;创建一张备份表，或者直接导出完整的 SQL 文件。 - 先验证：把
DELETE语句先改成SELECT语句，看看即将被删除的到底是哪些行。例如：SELECT id, email FROM users WHERE id NOT IN (SELECT MIN(id) FROM users GROUP BY email);确认无误后再执行删除。 - 加事务：将整个删除操作包裹在
BEGIN TRANSACTION;和COMMIT;之间。一旦发现删错了或者过程有误，立即执行ROLLBACK;，数据就能恢复原状。
说到底，最麻烦的从来不是语法怎么写，而是你能否准确理解“重复”背后的业务含义。举个例子，同一个邮箱地址，可能既对应一个注册账号，又关联一条客服工单。如果只看邮箱就判定为重复而删除一条，很可能就断掉了某个关键的用户流程。所以，动手之前，花点时间搞清楚字段的语义，远比写出十条完美的 DELETE 语句更重要。
