GROUP BY 本身不清洗数据但能暴露脏数据，需结合 COUNT(*) 查重复、MIN/MAX 检字段不一致、CASE WHEN + HAVING 识异常分布，并通过子查询或 JOIN 实现清洗操作。
GROUP BY 本身不清洗数据，但它能暴露脏数据、辅助清洗决策——关键在于你用它查什么、怎么分组、是否结合 HAVING 或子查询。
GROUP BY 配合 COUNT(*) 找重复记录
这是最直接的清洗入口：重复行往往意味着主键缺失、ETL 错误或业务逻辑异常。单纯 DISTINCT 会掩盖细节，而 GROUP BY + COUNT(*) 能告诉你“哪里重复、重复几次、哪些字段组合不稳定”。
- 查出所有重复的
order_id（假设它该唯一）：SELECT order_id, COUNT(*) AS cnt FROM orders GROUP BY order_id HAVING COUNT(*) > 1; - 查出哪些
(user_id, product_id, order_date)组合出现多次（可能是下单重试未去重）：SELECT user_id, product_id, order_date, COUNT(*) AS cnt FROM orders GROUP BY user_id, product_id, order_date HAVING COUNT(*) > 1; - 注意：如果
order_date是DATETIME类型，秒级精度可能导致看似重复实为不同时间点，此时应考虑按日期截断：DATE(order_date)。
GROUP BY + MIN/MAX 检测字段值不一致
当某字段在逻辑上应与分组键函数依赖（比如一个 user_id 对应唯一 region），但实际数据不满足时，MIN() 和 MAX() 的差异就是脏数据信号。
- 检查
user_id是否真对应唯一region：SELECT user_id, MIN(region) AS min_r, MAX(region) AS max_r FROM users GROUP BY user_id HAVING MIN(region) != MAX(region);
只要结果非空，就说明这个user_id在多条记录里存了不同region，必须清洗。 - 同理可查
email、phone、status等本该稳定的字段。 - 别用
AVG()或SUM()测字符串一致性——它们会隐式转换或报错；MIN()/MAX()是安全且语义清晰的选择。
GROUP BY + CASE WHEN + HAVING 定位异常分布
清洗不只是去重和纠错，还包括识别不符合业务常识的分布模式。这时要把业务规则“翻译”成分组条件。
- 查出订单金额异常集中的用户（比如单个用户占全站 30% 以上销售额）：
SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id HAVING SUM(amount) > (SELECT 0.3 * SUM(amount) FROM orders); - 查出“同一地址出现过多不同姓名”的记录（可能是代下单或爬虫）：
SELECT address, COUNT(DISTINCT name) AS name_cnt FROM orders GROUP BY address HAVING COUNT(DISTINCT name) > 5; - 注意：这类查询常需嵌套或 CTE，避免在
HAVING中直接引用外部聚合结果（部分数据库不支持），优先用子查询或窗口函数预计算全局基准值。
GROUP BY 后不能直接 UPDATE，必须用子查询或 JOIN
很多人想当然写 UPDATE ... GROUP BY，这是语法错误。SQL 标准中 UPDATE 不支持 GROUP BY 子句，清洗动作必须拆解。
- 错误写法：
UPDATE users SET region = '未知' WHERE user_id IN (SELECT user_id FROM users GROUP BY user_id HAVING MIN(region) != MAX(region));
（虽然某些 MySQL 版本能跑，但语义模糊、不可靠） - 正确做法是先用
GROUP BY识别问题键，再通过JOIN或IN关联原表更新：UPDATE users u JOIN (SELECT user_id FROM users GROUP BY user_id HAVING MIN(region) != MAX(region)) bad ON u.user_id = bad.user_id SET u.region = '待核实'; - 更安全的方式是把清洗逻辑写进临时表或 CTE，确认无误后再执行
UPDATE或DELETE。
真正难的不是写出 GROUP BY 语句，而是判断哪个字段组合能暴露你想清洗的问题——这取决于你对业务主键、函数依赖、数据生命周期的理解。一旦分组键选错，后面全是假阳性。
