用GROUP BY+HAVING可筛选重复值：先按目标列分组，再用HAVING过滤聚合结果；WHERE不能用于聚合条件。若需完整重复记录，可用窗口函数COUNT(*) OVER(PARTITION BY col)。
用 GROUP BY + HAVING 找出重复值
直接筛选重复数据，核心是分组统计后过滤——GROUP BY 按目标列分组，HAVING 对分组结果加条件。不能用 WHERE，因为行级条件无法作用于聚合结果。
常见错误是写成 WHERE COUNT(*) > 1，这会报错：聚合函数不能出现在 WHERE 子句中。
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 1- 如果只要重复的
user_id值本身，可省略COUNT(*)字段；若还需知道重复几次，就保留 -
HAVING必须紧跟GROUP BY，顺序不能颠倒
查出所有重复行的完整记录（不止去重后的值）
上面方法只返回分组键和计数，但业务常需要看到每条重复的原始数据，比如要人工核对或导出处理。
这时得用窗口函数或子查询关联。MySQL 8.0+、PostgreSQL、SQL Server 都支持 COUNT() OVER()，最简洁：
SELECT * FROM (SELECT *, COUNT(*) OVER (PARTITION BY email) AS cnt FROM users) t WHERE cnt > 1- 注意
PARTITION BY email是按email分组计数，不改变原行数 - 旧版 MySQL（IN 子查询，性能较差且易漏空值
NULL 值是否被当作重复？
默认情况下，GROUP BY 和 PARTITION BY 都把所有 NULL 归为同一组——也就是说，多个 NULL 会被算作一次重复。
如果业务上认为 NULL 不代表相同含义（例如“未填写”彼此无关），就得提前排除或单独处理：
- 加条件
WHERE column_name IS NOT NULL再分组 - 或用
COALESCE(column_name, 'UNSET_' || RANDOM())（PostgreSQL）等技巧让每个NULL变成唯一值 - 不同数据库对
NULL的分组行为一致，但显式处理更可控
性能关键点：别忘了加索引
对高频查询的去重列，没索引时 GROUP BY 会触发全表扫描+临时文件排序，百万级表可能秒变分钟级。
建索引不是“可选优化”，而是必要前置动作：
CREATE INDEX idx_user_email ON users(email);- 复合场景如查
(status, created_at)重复，考虑联合索引，顺序按查询中GROUP BY的列顺序来 - 注意索引无法加速
LIKE '%abc'这类前导通配，但纯等值重复检查完全能命中索引
实际跑慢的时候，先看执行计划里有没有 Using temporary; Using filesort——有就是索引没起作用，不是 SQL 写得不够巧。
