GROUP BY字段未对齐SELECT非聚合列是常见误判原因，如SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id会报错或返回随机name值；需确保非聚合字段全在GROUP BY中或用聚合函数包裹。
GROUP BY字段没对齐SELECT非聚合列
这是最常见也最容易被当成“重复”的误判。比如写SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id，数据库（PostgreSQL、SQL Server、MySQL 5.7+）会直接报错：column "name" must appear in the GROUP BY clause or be used in an aggregate function。旧版MySQL可能不报错，但name值是随机取的——你看到“重复”，其实是同一user_id组里每次查到的name碰巧一样，下次就可能不同。
- 检查
SELECT里每个非聚合字段（如name、status）是否都出现在GROUP BY子句中 - 如果该字段在组内不唯一，必须用聚合包裹，比如
MAX(name)、STRING_AGG(name, ',')或GROUP_CONCAT(name) - 别依赖
ONLY_FULL_GROUP_BY关闭后的宽松行为——上线换环境就崩
JOIN导致行数膨胀，分组前已重复
多表关联时，一对多关系没处理好，会在GROUP BY执行前就把数据撑开。比如订单主表orders和明细表order_items直接JOIN，一个订单有3条明细，就变成3行；再按order_id分组，COUNT(*)变成3，但其他字段（如客户名）会重复出现3次——这不是分组问题，是连接逻辑错了。
- 先在子查询里对从表聚合（如
SELECT order_id, SUM(amount) AS total FROM order_items GROUP BY order_id），再和主表JOIN - 临时加
COUNT(*) OVER (PARTITION BY order_id)看主键是否被放大，确认是不是JOIN惹的祸 - 避免
SELECT *+JOIN+GROUP BY三连套——字段越多越容易漏掉维度
HAVING条件写在WHERE里，根本没生效
想筛出重复组却写了WHERE COUNT(*) > 1，这语法直接报错：aggregate functions are not allowed in WHERE。因为WHERE在分组前执行，压根看不到COUNT()结果。
- 重复判定必须走
GROUP BY ... HAVING COUNT(*) > 1 -
HAVING过滤的是分组后的结果集，WHERE过滤的是分组前的原始行 - 如果要结合业务条件（比如只查未删除的记录），
WHERE写在GROUP BY之前，HAVING写在之后
NULL值被归为一组，但业务上不算“重复”
GROUP BY email会把所有email IS NULL的行合并成一组，COUNT(*)可能远超1——但这不是数据异常，是SQL标准行为。如果业务认为“邮箱为空”不等于“邮箱相同”，这种“重复”就是假阳性。
- 提前过滤：
WHERE email IS NOT NULL - 或统一转换：
GROUP BY COALESCE(email, '')或GROUP BY IFNULL(email, '') - 字符串字段还要防空格和大小写：
GROUP BY TRIM(UPPER(email))
真正难排查的，往往是JOIN和NULL混在一起：一行数据因JOIN被复制多次，其中某些字段又为NULL，分组时既被撑开又被合并，最后结果既不像全重复也不像全唯一——得拆开看执行计划，逐层验证中间结果。
