GROUP BY + HAVING COUNT(*) > 1 是定位重复记录的标准解法；需注意WHERE不能用聚合函数、NULL默认参与分组、查完整重复行需子查询或ROW_NUMBER()，后者更灵活但依赖版本与排序。
GROUP BY + HAVING COUNT(*) > 1 是最直接有效的识别方式
想快速知道哪些数据行重复了，别绕路写多层子查询或临时表——GROUP BY配合HAVING COUNT(*) > 1就是标准解法。它在分组后统计每组行数，再过滤出真正重复的组，语义清晰、执行快、兼容 MySQL、PostgreSQL、SQL Server 和 Oracle。
常见错误是把COUNT(*)塞进WHERE里，结果报错：ERROR: aggregate functions are not allowed in WHERE。因为WHERE在分组前执行，根本还没算出数量。
-
GROUP BY的字段必须是你判断“是否重复”的依据，比如email、order_no，或多列组合如name, phone -
HAVING是唯一能对聚合结果做条件筛选的子句，WHERE不能替代 - 如果只关心“哪些值重复”，
SELECT里只需写GROUP BY字段；想看次数，就加COUNT(*)
查完整重复行时，IN 子查询容易漏掉 NULL 或性能崩
上面的方法只能告诉你“email为 abc@example.com 的记录重复了”，但业务上往往需要导出所有重复的原始行（含id、created_at等），这时得用IN子查询回查原表。
典型写法：
SELECT * FROM users WHERE email IN ( SELECT email FROM users GROUP BY email HAVING COUNT(*) > 1 );
但这里有两个硬伤：
- 如果
email列有NULL，IN会彻底失效——col IN (..., NULL)永远不返回true，必须显式补上OR email IS NULL，并在子查询中单独处理NULL组 - 大表（比如百万级）上没索引时，
IN会触发两次全表扫描；确保目标列有索引，例如CREATE INDEX idx_email ON users(email) - MySQL 8.0+ 或 PostgreSQL 可改用
JOIN避开IN陷阱，但逻辑更重，小数据量够用就行
ROW_NUMBER() 能精准标记每条重复行，但要注意排序和版本
当你要区分“第一次出现”和“后续重复”，或者准备删掉冗余只留最新一条，ROW_NUMBER()比GROUP BY更可控。它不改变原结构，只给每行打上组内序号。
示例：
SELECT *, ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn FROM users;
之后可直接筛选：
- 全部重复副本：
WHERE rn > 1 - 每组保留最早一条：
WHERE rn = 1 - 只取重复组的首尾两条：
WHERE rn IN (1, 2)
注意点：
- SQLite 在 3.25.0 之前不支持
ROW_NUMBER()，旧版本得换方案 -
PARTITION BY字段顺序和ORDER BY直接影响编号结果，漏写ORDER BY会导致编号随机 - 若按时间排序，注意
created_at是否允许NULL，否则NULL可能排在最前或最后，影响“保留谁”的逻辑
整行完全重复时，GROUP BY 所有列要小心 NULL 处理
当表没有主键或业务唯一键，又怀疑存在完全相同的行（所有字段值都一样），就得把所有列放进GROUP BY。但这事容易翻车。
问题核心在NULL：多数数据库中NULL = NULL为false，但GROUP BY会把多个NULL归为同一组——这其实是标准行为，但常被误认为 bug。
- 如果业务上认为多个
NULL不算重复，得提前排除：WHERE col1 IS NOT NULL AND col2 IS NOT NULL ... - 如果想把
NULL当作普通值统一处理，用COALESCE(col, 'N/A')转换，避免分组失真 - 字段太多时手动列全很麻烦，可先用
SELECT column_name FROM information_schema.columns WHERE table_name = 'xxx'生成字段列表，再拼接
真正难的不是写出来，而是确认“重复”的定义本身——是单字段、多字段组合，还是整行？没厘清这点，再漂亮的 SQL 也救不了数据逻辑。
