写SQL查了几年数据，最怕碰到的就是having子句。刚入门那会儿，我总觉得where和having长得差不多，都是过滤条件，到底该用哪个？直到有一次，我在一个几百万行的订单表上，用where把分组后的汇总数据给过滤了，结果直接报错，那一刻我才意识到，这俩兄弟压根不是一回事。
where是在分组之前干活，一行一行地筛选原始数据，筛完才轮到group by分组。having呢，是在分组完成之后，对每个小组的结果进行过滤。这么一说好像挺简单，但实际操作中，很多人还是容易绕进去。举个例子，你想查每个城市订单金额超过100的客户数量，这个“超过100”如果是对每个客户而言，那得用where先筛掉金额不够的客户，再分组计数；但如果是对每个城市的总金额来说，那就得先按城市分组，算出总金额，再用having把总金额不足100的城市淘汰掉。顺序搞反了，结果就全乱了。
我见过不少同事，写having的时候习惯性地把分组字段之外的普通列放进去，比如having name = '张三'，然后数据库直接甩给你一个错误：not a GROUP BY expression。这倒不是数据库矫情，而是逻辑上说不通——分组之后，每个组里可能有几十个名字，你让数据库怎么判断等于张三还是李四？所以having后面能放的，要么是分组字段本身，要么是聚合函数的结果，比如sum(amount) > 5000、count() >= 10、avg(price) between 20 and 50，这些才有意义。
再说个容易忽略的细节，having和where可以同时出现，而且顺序固定：where先过滤行，group by分组，having过滤组，才是order by排序。我见过有人把having写在where前面，数据库倒是能容忍，但可读性差得离谱，你同事看了估计心里在骂人。规范写法永远是where在前，having在后，中间隔着group by，这个顺序别打乱。
实际业务里，having最常见的用法是配合group by做“组级别的筛选”。比如运营要看每个品类的退货率，你先按品类分组，算出退货订单数和总订单数，然后having退货率 > 0.3，把那些退货率超标的品类揪出来。这种场景下，如果你用where去写退货率大于0.3，数据库根本不知道退货率是什么，因为这是分组之后才计算出来的指标。再比如电商大促后，你想找出那些客单价低于50元但订单量超过1000的店铺，这就是典型的having双条件——avg(amount) < 50 and count() > 1000。
还有个挺实用的技巧，having里可以直接写别名，但前提是别名在select里已经定义了。比如select city, sum(amount) as total from orders group by city having total > 500，这样写没问题，数据库能认出来。不过有些数据库版本对having里的别名支持不友好，比如早期的MySQL版本就有点任性，为了保险起见，我建议你直接写完整的聚合表达式，别偷懒用别名，省得换了个数据库环境就莫名其妙报错。
再聊一个容易踩的坑，就是having和distinct搞在一起。distinct是去重，having是过滤组，俩人的职责完全不同。有人想查“出现次数超过5次的不同用户ID”，写成select distinct userid from orders having count() > 5，这逻辑就乱了——distinct去重之后，count()数的是去重后的行数，跟原始分组完全对不上。正确的姿势是先按userid分组，having count(*) > 5，再用distinct或者直接group by本身就能保证唯一性，压根不需要distinct画蛇添足。
如果你经常跟报表打交道，可能还会遇到一个更高级的玩法——在having里用子查询。比如你想找出那些销售额高于全公司平均水平的区域，可以先写一个子查询算出整体平均值，然后having sum(amount) > (select avg(total) from ...)。这种嵌套虽然能跑通，但我劝你谨慎使用，因为性能上往往不太友好，数据量一大就容易卡死。更聪明的做法是提前算好平均值存到临时表里，或者用窗口函数替代，效率高得多。
聊了这么多，给你一个实战口诀：先where再group by，having永远站在分组后。凡是过滤原始行数据的，通通扔给where；凡是过滤分组汇总结果的，必须用having。下次写SQL的时候，脑子里过一遍这个顺序，基本就不会错了。数据库的having子句，说白了就是给你一把尺子，量的是分组之后的结果，而不是每一块原材料。记住这点，你就能在数据的世界里少走不少弯路，把那些藏在分组里的异常值、高价值客户、问题品类，一个不落全给揪出来。
