用GROUP BY+HAVING查重复值最直接：先按字段分组，再用HAVING筛选COUNT(*)>1的组；注意WHERE不能替代HAVING，NULL会被归为一组，多字段需全列在GROUP BY中，加索引可大幅提升性能。
用 GROUP BY + HAVING 找出重复值最直接
想快速定位某个字段（比如 email 或 user_id）重复的数据，核心思路是：先按该字段分组，再筛选出组内行数大于 1 的那些组。这比用子查询或自连接更轻量、可读性更好。
常见错误是漏写 HAVING，误用 WHERE——WHERE 在分组前过滤，无法判断“组内数量”，必须用 HAVING 对聚合结果做条件筛选。
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1- 如果还要看具体哪些记录重复，可搭配
IN子查询：SELECT * FROM users WHERE email IN (SELECT email FROM users GROUP BY email HAVING COUNT(*) > 1) - 注意：MySQL 8.0+ 和 PostgreSQL 支持窗口函数，但简单查重场景没必要上
ROW_NUMBER()，性能反而略低
查重复时别忽略 NULL 值的特殊行为
绝大多数数据库中，NULL = NULL 返回 UNKNOWN，不是 TRUE，所以 GROUP BY 默认会把所有 NULL 归为同一组——这意味着多个 NULL 也会被判定为“重复”。这常被当成 bug，其实是符合 SQL 标准的。
- 如果业务上认为
NULL不代表相同含义（比如“未填写”彼此不重复），需提前排除：SELECT phone, COUNT(*) FROM contacts WHERE phone IS NOT NULL GROUP BY phone HAVING COUNT(*) > 1 - 若必须把
NULL当作普通值参与去重逻辑，PostgreSQL 可用GROUP BY phone IS NULL, phone拆开处理；MySQL 则常用COALESCE(phone, CONCAT('NULL_', RAND()))临时打标（仅调试用）
多字段联合重复检测要写全 GROUP BY 列表
检查组合唯一性（如 order_id + sku_id 是否重复）时，GROUP BY 必须包含所有用于判断重复的字段，缺一不可。少写一个，分组粒度就变粗，结果就错。
- 正确：
SELECT order_id, sku_id, COUNT(*) FROM order_items GROUP BY order_id, sku_id HAVING COUNT(*) > 1 - 错误：
GROUP BY order_id—— 这只会告诉你哪个订单里有多个商品，不是“同一订单+同一SKU重复” - 如果字段多、手动列太麻烦，可考虑先建临时唯一索引：
CREATE UNIQUE INDEX idx_order_sku ON order_items (order_id, sku_id)，失败时的报错信息会直接指出冲突行（适合一次性校验）
大数据量下加索引能显著提速
没索引时，GROUP BY 会触发全表排序或哈希构建，千万级表可能卡住。对高频查重字段加索引是最有效的优化手段。
- 单字段：直接在该字段建 B-tree 索引，例如
CREATE INDEX idx_email ON users(email) - 多字段：建联合索引，顺序按
GROUP BY中字段顺序来，如CREATE INDEX idx_order_sku ON order_items(order_id, sku_id) - 注意：索引本身不解决逻辑问题，但能让
HAVING COUNT(*) > 1从分钟级降到秒级——尤其当重复率很低时，索引能快速跳过大量非重复数据
查重复看似简单，但 NULL 处理、多字段分组完整性、以及生产环境没索引导致的性能断崖，这三个点最容易在线上突然暴露。
