DELETE不能与GROUP BY直接联用，因SQL标准禁止在删除操作中使用分组聚合逻辑；必须通过ROW_NUMBER()配合CTE或子查询先标记重复行，再按序号删除冗余记录。
为什么不能直接用 DELETE + GROUP BY 删除重复行
SQL 标准不支持在 DELETE 语句中直接使用 GROUP BY 或聚合函数，所以像 DELETE FROM t GROUP BY col1, col2 HAVING COUNT(*) > 1 这种写法会报错（常见错误：ERROR: syntax error at or near "GROUP"）。必须借助可定位具体行的机制，比如给每组重复数据编号，再保留编号为 1 的行、删掉其余的。
用 ROW_NUMBER() + CTE 实现去重删除的核心逻辑
ROW_NUMBER() 能按指定列分组排序并生成唯一序号，CTE（公用表表达式）则提供一个临时命名结果集，让 DELETE 可以引用它。关键在于：把重复判断逻辑放进 ROW_NUMBER() 的 PARTITION BY 子句里，再在外部 DELETE 中过滤掉序号大于 1 的行。
示例（PostgreSQL / SQL Server / Oracle / DuckDB 均适用）：
WITH dupes AS (
SELECT id, name, email,
ROW_NUMBER() OVER (
PARTITION BY name, email
ORDER BY id ASC
) AS rn
FROM users
)
DELETE FROM users
WHERE id IN (SELECT id FROM dupes WHERE rn > 1);-
PARTITION BY name, email表示“把 name 和 email 都相同的行划为一组” -
ORDER BY id ASC决定哪一行被保留——这里保留id最小的那条，若想留最新插入的，改用ORDER BY id DESC - 注意：CTE 中必须包含能唯一标识原表行的字段（如主键
id），否则DELETE无法安全关联 - MySQL 8.0+ 支持该写法；MySQL 5.7 及更早版本不支持 CTE 中嵌套
DELETE，需改用自连接或临时表
不同数据库的兼容性陷阱
不是所有数据库都允许 CTE 直接参与 DELETE 的 FROM 子句，尤其当目标表和 CTE 引用同一张表时。
- PostgreSQL：支持上述写法，但需确保 CTE 查询中包含主键，且
DELETE使用IN或USING关联（上面是IN方式，稳妥） - SQL Server：推荐用
DELETE FROM users WHERE id IN (SELECT id FROM ...)形式，避免DELETE FROM cte_name（后者在某些版本中不可更新） - MySQL 8.0：支持，但必须开启
cte_max_recursion_depth（默认够用），且 CTE 不能引用将被修改的表名作为别名（即不能写WITH dupes AS (SELECT * FROM users u) DELETE FROM users...） - SQLite：不支持窗口函数，
ROW_NUMBER()不可用，得换用子查询 + 自连接方式
执行前必须验证的三件事
这条语句一旦执行就不可逆，务必先确认要删的是什么。
- 先运行 CTE 查询部分，检查
rn > 1的行是否真是你想删的重复项：WITH dupes AS ( SELECT id, name, email, ROW_NUMBER() OVER (PARTITION BY name, email ORDER BY id ASC) AS rn FROM users ) SELECT * FROM dupes WHERE rn > 1; - 确认
PARTITION BY列是否覆盖了全部重复判定维度（比如漏了phone，可能导致本该合并的用户被误删） - 生产环境操作前，用
BEGIN TRANSACTION包裹（PostgreSQL/SQL Server），或先备份关键字段：CREATE TABLE users_backup AS SELECT * FROM users WHERE id IN (SELECT id FROM dupes WHERE rn > 1);
真正麻烦的不是语法，而是「哪些列才算重复」这个业务定义——它决定了 PARTITION BY 里写什么，也决定了删完之后数据语义是否还成立。
