用 GROUP BY username HAVING COUNT(*) > 1 快速查重复用户名；WHERE 不能用聚合函数；DISTINCT 无法统计重复次数；HAVING 在分组后过滤，WHERE 在分组前过滤；NULL 被视为相同值参与分组。
怎么快速找出表里重复的用户名
直接用 GROUP BY 配合 HAVING，别先 SELECT * 再人工扫——慢还容易漏。核心是把要判断重复的字段（比如 username）作为分组依据，再用 HAVING COUNT(*) > 1 筛出至少出现两次的组。
- 错误写法：
WHERE COUNT(*) > 1——COUNT是聚合函数，不能在WHERE里用，会报错ERROR: aggregate functions are not allowed in WHERE - 正确顺序必须是：
GROUP BY→ 聚合计算 →HAVING过滤 - 如果只要重复值本身（不要计数），
SELECT username就够了；如果还要看重复几次，就加COUNT(*) AS cnt
统计重复时为什么不能用 DISTINCT
DISTINCT 只能去重，不能告诉你“谁重复了”或“重复几次”。它像筛子，只留下一个，不保留上下文信息。
- 想查“哪些邮箱被注册了三次”，
DISTINCT email返回的是唯一邮箱列表，完全没提次数 -
GROUP BY email HAVING COUNT(*) = 3才能精准命中目标 - 性能上，
GROUP BY通常比嵌套子查询 +DISTINCT更快，尤其数据量大时，数据库能利用索引加速分组
HAVING 和 WHERE 的区别到底在哪
本质是执行时机不同：WHERE 在分组前过滤行，HAVING 在分组后过滤组。这个顺序不能颠倒。
- 比如要查“2023年注册的重复用户名”，日期条件得放
WHERE created_at >= '2023-01-01'，而不是HAVING—— 否则会先分组再过滤年份，逻辑错乱 -
HAVING只能引用SELECT中出现的分组字段或聚合表达式，比如HAVING AVG(price) > 100合法，但HAVING status = 'active'会报错（除非status在GROUP BY里） - 有些方言（如 MySQL 5.7+）允许
SELECT列不在GROUP BY中，但标准 SQL 和 PostgreSQL 会直接拒绝——这是容易被忽略的兼容性坑
遇到 NULL 值重复怎么处理
NULL 在 GROUP BY 中被视为相同值，所以多个 NULL 会被归到同一组，COUNT(*) 也会把它们算进去。这点常被误以为“NULL 不参与分组”。
- 如果业务上认为
NULL是未知，不该算作重复，得提前用COALESCE(email, '')或CASE WHEN email IS NULL THEN 'unknown' ELSE email END替换 - 验证方法：执行
SELECT email, COUNT(*) FROM users GROUP BY email ORDER BY COUNT(*) DESC LIMIT 5，看结果里有没有NULL对应的高计数 - 注意：某些 ORM（如 Django ORM）生成的
GROUP BY语句默认不包含NULL安全选项，需手动处理
