写这篇文章的起因很实在前几天帮团队做代码评审一位同事写了一条统计SQL大意是查出销售金额超过一万的订单明细结果他把SUM(amount) 10000直接写进了WHERE子句数据库当场就报错“Invalid use of group function”。他愣了半天没想明白为什么同样的条件放在HAVING里就能跑通。这个问题其实特别典型也是MySQL里HAVING子句最容易被卡住的地方。HAVING是MySQL的SELECT七大子句里非常特殊的一个。它和WHERE长得像功能也像但作用时机完全不同。很多人把SQL当英语读觉得HAVING就是“又一个过滤条件”结果一遇到聚合函数就翻车。这篇文章我会把HAVING从执行时机、语法限制、与WHERE的本质区别到常见坑点和优化思路全部拆开揉碎讲清楚。不管你是刚开始写SQL的新手还是被慢查询折磨的运维老手这篇文章都能帮你在HAVING这里少踩几个坑。1. 理解having的前提先看select子句的执行链路单独背HAVING的语法没有意义它所有的“疑难”都出在“它在什么时候执行”这件事上。MySQL的SELECT语句虽然书写顺序是SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ... LIMIT但逻辑执行顺序完全不是这样。1.1 七大select子句的逻辑执行顺序一条完整的带聚合的查询内部执行顺序大致是这样的FROM确定数据源加载表如果有JOIN就在这一步做连接。WHERE对FROM产出的行做逐行过滤此时聚合函数还没登场。GROUP BY把过滤后的行按指定列分组。HAVING对分组后的结果做过滤此时聚合函数可以出场了。SELECT计算并输出最终要返回的列包括表达式、别名等。DISTINCT对结果去重如果写了的话。ORDER BY对最终结果排序。LIMIT限制返回行数。你可以把整个流程想象成一条流水线FROM是原料入库WHERE是第一道粗筛把不合规的原始行直接扔掉GROUP BY把留下的行装进不同的箱子HAVING是对整箱货物做质检——不合格的整箱淘汰最后才轮到SELECT打标签、ORDER BY排队、LIMIT限流。这个类比看起来简单但它能解决一个很大的认知误区WHERE看不到聚合结果因为它在分组之前就跑完了HAVING看不到原始行因为它处理的已经是分组后的箱子。1.2 执行顺序对having的三个直接影响理解了执行链路很多规则就顺理成章了。第一WHERE里不允许出现聚合函数。因为聚合是分组阶段才做的事情第一道粗筛工序的机器还没有聚合能力你让它做SUM()它自然报错。必须把含聚合函数的过滤条件放到HAVING。第二SELECT里的别名在HAVING阶段通常不可用。因为别名是在SELECT阶段才定义的而HAVING先于SELECT执行。MySQL确实对HAVING引用别名做了一些放宽后面会专门讲但其他数据库比如SQL Server在这一点上非常严格跨数据库写SQL的人很容易踩坑。第三WHERE过滤掉的原始行不会进入GROUP BY也就不会影响聚合结果而HAVING是在聚合之后过滤它不会减少聚合的计算量只影响最终输出。这一点直接决定了一条SQL是先用WHERE还是先用HAVING后面性能优化那节我会展开说。2. having与where表面相似本质不同的过滤双雄很多MySQL教程一讲到HAVING就是一句“为分组过滤条件使用”但没有解释为什么需要这样一个看似重复的子句。在我看来HAVING和WHERE的关系像是面试中的“简历初筛”和“终面”初筛先筛掉明显不匹配的人终面再根据综合素质判断是否录用。两道工序缺一不可因为它们的判断依据完全不同。2.1 一张表说清where与having的核心区别对比维度WHEREHAVING执行时机GROUP BY之前GROUP BY之后过滤对象原始行分组后的组能否使用聚合函数不能可以能否引用SELECT别名通常不能MySQL中可以其他数据库严格受限对性能的影响减少分组数据量通常可用索引优化在聚合完成后过滤无法通过索引过滤与GROUP BY的关系可以不写GROUP BY单独使用常与GROUP BY配合但也可以单独使用这张表的核心就一句话WHERE在分组前过滤行HAVING在分组后过滤组。2.2 一个真实例子查找平均工资超过8000的部门假设有一张员工表employeesiddept_idsalary110120002106000320900042080005305000现在要查“平均工资超过8000的部门”正确的写法是SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id HAVING AVG(salary) 8000;结果只有部门10平均9000满足条件。这里AVG(salary)必须放在HAVING中因为平均值是分组之后才计算出来的WHERE阶段根本没有这个值。如果错误地写成SELECT dept_id, AVG(salary) AS avg_salary FROM employees WHERE AVG(salary) 8000 GROUP BY dept_id;MySQL会直接报错Invalid use of group function。原因在前面已经说了——WHERE执行时聚合函数还没开始计算它没有能力对聚合结果做判断。反过来还有一种情况如果需求是“先排除工资低于6000的员工再统计各部门的平均工资”那就必须用WHERE先过滤分组时只看到符合条件的行聚合结果自然也就不同SELECT dept_id, AVG(salary) AS avg_salary FROM employees WHERE salary 6000 GROUP BY dept_id HAVING AVG(salary) 8000;这个例子的意义在于WHERE和HAVING不是二选一的关系而是同一套逻辑里先后配合的两道关卡。前者过滤参与者后者过滤结果。3. having的实操要点能写什么、不能写什么、怎么写最稳HAVING的语法本身很简单真正让人头疼的是它里面到底能放什么条件。我见过不少同事在HAVING里写了非聚合列、写了别名、甚至写了DISTINCT结果每种写法都有自己的一套规则。这一节把这些问题全部整理出来。3.1 having里能放的条件类型HAVING的条件分为三类第一类是聚合函数条件这是HAVING的核心用途。常见的包括SUM()、COUNT()、AVG()、MAX()、MIN()、GROUP_CONCAT()等例如-- 只保留订单数量大于3的客户 SELECT customer_id, COUNT(*) AS order_cnt FROM orders GROUP BY customer_id HAVING COUNT(*) 3; -- 只保留总金额在1000到5000之间的分组 SELECT customer_id, SUM(amount) AS total_amount FROM orders GROUP BY customer_id HAVING SUM(amount) BETWEEN 1000 AND 5000;第二类是分组列条件。如果某列参与了GROUP BY它也可以在HAVING中出现例如SELECT dept_id, COUNT(*) AS emp_cnt FROM employees GROUP BY dept_id HAVING dept_id IN (10, 20, 30);不过这种情况我个人更推荐用WHERE去做因为分组列的条件在分组前就能过滤用WHERE性能更好语义也更清晰。第三类是非分组列直接条件这种写法在MySQL里是允许的但结果可能不同于直觉下面单独说。3.2 非聚合列直接出现在having里的坑先看这条SQLSELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id HAVING salary 8000;salary既不是GROUP BY的列也没有被聚合函数包裹。在MySQL中这条SQL大概率能跑通但它返回的结果可能是不确定的。原因在于分组后每个组里有多个salary值MySQL到底取哪一个去和历史条件比较完全依赖于执行计划和存储引擎的内部行为不可控。SQL标准要求HAVING中出现的非聚合列必须出现在GROUP BY中MySQL之所以允许是为了兼容某些历史场景。但从实践角度这种写法基本等于埋雷。如果确实要对非聚合列做条件判断要么把它加入GROUP BY要么用聚合函数包一层要么在WHERE阶段就过滤掉。3.3 having引用别名的兼容性陷阱MySQL在HAVING中允许引用SELECT中定义的别名例如SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id HAVING avg_salary 8000;这在MySQL里可以正常工作因为MySQL对HAVING的解析会做一次别名替换。但在SQL Server、Oracle等数据库中这种写法会直接报错Invalid column name avg_salary因为逻辑执行顺序中HAVING先于SELECT别名还不存在。所以如果你写的是跨数据库兼容的SQL务必不要在HAVING里用别名老老实实写完整聚合表达式。就算是只在MySQL中使用也建议正式代码里保持完整写法因为可读性和可移植性都会被拉高。3.4 having与distinct的冷门组合有些场景需要在分组后对某个字段去重再统计比如统计每个客户购买过的商品种类数这时候HAVING可以结合COUNT(DISTINCT ...)SELECT customer_id, COUNT(DISTINCT product_id) AS product_kind FROM orders GROUP BY customer_id HAVING COUNT(DISTINCT product_id) 5;还有一种少见的情况HAVING本身就带DISTINCT比如SELECT customer_id, COUNT(*) AS order_cnt FROM orders GROUP BY customer_id HAVING COUNT(DISTINCT order_date) 3;这表示筛出“下过至少4天订单”的客户而不是“下过4单”的客户。这个场景在统计活跃用户时非常实用但很多人想不到HAVING里还能再嵌套一层DISTINCT。唯一的提醒是COUNT(DISTINCT)在大表上性能开销很高能用小表先缩小范围的话尽量别一股脑全表跑。4. 疑难点逐个击破从分组、去重到join的复杂组合写HAVING的坑往往不是语法本身而是它和GROUP BY、JOIN、NULL值这些机制组合在一起时产生的各种行为。这一节我挑几个最常见的疑难点展开讲。4.1 group by与having的配合细节GROUP BY和HAVING是一对搭档但这里的细节很容易被忽略。第一GROUP BY会把NULL值单独分一组。比如统计员工表里各部门人数如果dept_id有NULL结果里会多出一行dept_id NULL的分组。如果你不想要这个分组可以用WHERE dept_id IS NOT NULL先行过滤或者用HAVING dept_id IS NOT NULL事后过滤。两者都可但前者通常性能更好。第二GROUP BY之后HAVING里可以用GROUP_CONCAT做一些很巧妙的判断。比如查“一个订单里包含商品A和商品B的订单号”SELECT order_id FROM order_items GROUP BY order_id HAVING GROUP_CONCAT(product_id ORDER BY product_id) LIKE %A%B%;这种写法虽然能跑但可读性稍差更常见的场景是统计某个分组里满足特定条件的记录条数再用HAVING过滤比如SELECT order_id FROM order_items WHERE product_id IN (A, B) GROUP BY order_id HAVING COUNT(DISTINCT product_id) 2;这个写法才是“同时包含A和B”的稳妥解法——先过滤出只和A、B相关的行再分组判断去重商品数是否为2等于2说明两个都有。第三GROUP BY和HAVING的过滤顺序直接决定了聚合结果是否包含被淘汰的数据。WHERE先过滤掉的数据不参与聚合HAVING过滤掉的是已经算完聚合结果的分组。这两者在统计含义上的差别比性能上的差别更值得注意。4.2 having在海量数据下的性能隐患很多人的认知是HAVING写得很爽反正它能过滤分组那就把条件全扔给它。这其实是个性能大坑。WHERE能在数据进入分组前减少数据量而且往往能利用索引直接定位到符合条件的行HAVING必须等GROUP BY把所有行分好组、把所有聚合函数算完才能逐组做判断。这意味着一行HAVING条件背后是整个表的分组计算代价。举个例子一张一千万行的订单表要查“下单次数超过10次且总金额超过一万的用户”。如果所有过滤都放在HAVING里MySQL就得先按user_id把一千万行全部分组再计算每个组的COUNT(*)和SUM(amount)最后才过滤。如果在WHERE阶段先加一个order_date之类的范围条件把数据量缩小到一百万行分组的代价直接小一个数量级。所以我的习惯是能用WHERE过滤的绝不放HAVINGHAVING里只放那些必须依赖聚合结果的条件。比如上面的例子合理写法是SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amount FROM orders WHERE order_date 2024-01-01 GROUP BY user_id HAVING COUNT(*) 10 AND SUM(amount) 10000;order_date的范围过滤走索引进入分组的行数变少聚合计算量大幅下降HAVING只负责最后的门槛判断。4.3 having与join组合时的常见误区多表JOIN之后再分组过滤很多人分不清楚WHERE该放哪、HAVING该放哪。核心规则不变过滤连接前原始行的条件放WHERE过滤分组聚合结果的条件放HAVING。假设有users表和orders表要查“2024年之后下单用户中平均客单价超过500元的城市”SELECT u.city, AVG(o.amount) AS avg_amount FROM users u JOIN orders o ON u.id o.user_id WHERE o.order_date 2024-01-01 GROUP BY u.city HAVING AVG(o.amount) 500;WHERE o.order_date 2024-01-01是在JOIN之后、GROUP BY之前执行的它先把不符合时间要求的订单行淘汰掉HAVING AVG(o.amount) 500是对每个城市分组做完平均值计算后再筛选。这两者的位置一旦写反统计口径和性能都会出问题。另外JOIN时如果使用LEFT JOIN关联不到匹配行的列会产生NULL值这些NULL值在GROUP BY时会被分到同一个组HAVING中如果用COUNT(orders.id)统计不会把NULL计入但用COUNT(*)会把NULL行也算进去。这一点非常阴险——明明是同一条SQL逻辑换一个聚合函数结果就变了。4.4 having别名的极限操作与分组序号MySQL还支持在HAVING中使用GROUP BY的序号比如SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY 1 HAVING AVG(salary) 8000;这里的GROUP BY 1表示按SELECT列表的第1列即dept_id分组。这种写法虽然节省了几个字符但可读性极差一旦SELECT列顺序调整结果就可能出错。在团队协作的正式代码里我一律不推荐用序号分组更不用说在HAVING里依赖于这种序号关系了。规范的第一优先级始终是可读性和可维护性。5. 常见问题与排查技巧实录写HAVING踩坑不可怕可怕的是踩了坑还不知道问题出在哪。这一节我把我实际遇到过的几类问题整理成了速查表每一类都附上排查思路和解决方向。5.1 having高频报错与解决方案速查表报错信息原因分析解决方案Invalid use of group function在WHERE中使用了聚合函数把聚合函数条件移到HAVINGUnknown column 别名 in having clause在HAVING中引用了SELECT别名但数据库解析顺序不允许改成完整聚合表达式或确认MySQL版本是否支持再使用Column xxx is invalid in the select list ... not contained in either an aggregate function or the GROUP BY clause在MySQL 5.7开启了only_full_group_by模式下SELECT中出现了非聚合非分组列调整SELECT列让它们要么被聚合要么出现在GROUP BY中结果里多出一个NULL分组GROUP BY列存在NULL值在WHERE阶段加列 IS NOT NULL过滤查询结果与预期不符HAVING过滤后数据变少HAVING中使用了非分组列条件MySQL取了某个不确定的值使用聚合函数包裹该列或把条件移到WHEREHAVING执行慢全表扫描GROUP BY前没有缩小数据量在WHERE增加范围条件尽量走索引5.2 一条真实排查记录orders 表现身说法有一次排查一个线上报表慢查询SQL大概是这样的SELECT seller_id, COUNT(*) AS order_cnt FROM orders GROUP BY seller_id HAVING order_cnt 100 ORDER BY order_cnt DESC LIMIT 10;这条SQL在数据量小的时候跑得飞快但数据量到了千万级之后每次查询都要等好几秒。原因是HAVING order_cnt 100里引用了SELECT别名——MySQL允许这种做法但它本质上必须等GROUP BY把全量数据分组并计算出COUNT(*)之后才能拿着结果去过滤。也就是说哪怕最终只需要10个卖家MySQL依然把几千万行全部聚合了一遍。优化思路有两个方向。方向一是把过滤条件下沉到子查询里但这里HAVING本身已经是对聚合结果的过滤没法再下沉到WHERE。真正可行的做法是给表加合适的索引减少GROUP BY的排序成本或者在应用层做缓存把低频全量报表换成预计算任务。方向二是如果业务允许可以先用一个WHERE条件缩小时间窗口比如只看近30天的数据这样进入GROUP BY的行数大大减少。那次排查给我的教训是HAVING里的别名看着方便但一条SQL里如果HAVING条件和ORDER BY都依赖别名执行计划往往不会有多聪明优化的突破口经常在源头数据量控制上而不是在HAVING写法本身上。5.3 写having容易忽略的三个细节第一HAVING在没有GROUP BY的时候也可以单独使用。这种情况下整张表会被当成一个大组HAVING相当于对整个表的聚合结果做过滤。比如SELECT COUNT(*) FROM employees HAVING COUNT(*) 100;这条SQL合法意义是“如果公司员工超过100人就返回总人数否则返回空结果集”。但写成这样可读性并不高建议用子查询或直接对结果做判断。第二HAVING的滞后性会让你忽略真实的数据量成本。我在实际开发中见过有人习惯把所有过滤条件都塞进HAVING觉得“反正SQL能跑就行”结果一到线上数据量上来就崩。永远记住能在WHERE里过滤掉的绝不留给HAVING。第三也是很多规范文档里不会提的HAVING和ORDER BY的执行顺序在MySQL中同样是HAVING先于ORDER BY。所以如果ORDER BY里引用了别名那是在SELECT阶段之后才能解析的内容不会反过来影响HAVING的过滤范围。搞清楚这个顺序你在调试“为什么排序结果不对”的时候能少走很多弯路。6. 从having延伸出去面试题与SQL优化直觉HAVING是MySQL面试里的高频考点也是很多人从“会写SQL”到“理解SQL”之间的一道分水岭。这一节把常见的面试题做一个梳理同时分享两个我总结的优化直觉。6.1 面试常问的几个having问题第一题“WHERE和HAVING有什么区别”回答框架就三条执行时机不同一个在GROUP BY前、一个在后能否使用聚合函数不同WHERE不能、HAVING可以过滤对象不同一个过滤行、一个过滤分组。再补一句性能上的直觉能用WHERE的优先用WHERE因为它减少的是进入分组的源数据量。第二题“HAVING里能不能用SELECT的别名”在MySQL里可以但不建议依赖在SQL标准和其他主流数据库中通常不行。回答时最好能说出原因——逻辑执行顺序中HAVING先于SELECT执行别名还没有被定义。第三题“一条SQL的执行顺序是什么”除了标准的八步链路之外能答出WHERE聚合不行、HAVING引用别名不行这类细节才算真正理解。面试官往往不是要你背全套顺序而是看你能不能用它解释实际遇到的问题。第四题“COUNT(*)和COUNT(column)在HAVING里的区别”COUNT(*)统计所有行包括NULLCOUNT(column)会跳过该列为NULL的行。这个细节在LEFT JOIN场景下特别容易踩坑具体例子前面已经说过。6.2 实用的优化直觉优先缩小数据集我写SQL的准则之一是做任何操作之前先问自己“这个阶段我处理了多少行”一个好的SQL是逐步缩小数据集的WHERE缩小到可接受的范围GROUP BY在这个范围内做聚合HAVING只过滤少数不符合条件的组最后ORDER BY和LIMIT只处理极少量数据。如果把过滤全部放在HAVING等于把分组聚合当成全表操作来完成性能自然是灾难。所以优化HAVING相关查询最有效的不是去调整HAVING本身的写法而是回头看WHERE是否漏掉了可以提前过滤的条件以及GROUP BY能否借助索引避免文件排序。经常是加一个合适的索引原来慢如蜗牛的GROUP BY HAVING查询立刻变得飞快因为分组操作直接通过索引的有序性完成了连排序临时文件都省了。6.3 从having到完整查询设计的小结HAVING不是一个孤立的关键字它是整个SELECT查询链条的产物。理解了它的执行时机就理解了WHERE、GROUP BY、聚合函数、别名、索引优化之间的相互关系。很多MySQL高手的功力并不是体现在背了多少语法而是看到一个慢查询能凭直觉判断出瓶颈是在WHERE的索引使用还是在GROUP BY的分组成本还是在HAVING的滞后过滤。这种直觉说白了就是对查询执行顺序的内化。在我自己写SQL的习惯里最后一个动作永远是回过头检查一遍每个子句的执行位置这个条件真的不能下沉到WHERE吗这个别名会不会影响其他数据库的兼容性分组前的数据量是不是已经被压缩到最小了这些审视比任何语法记忆都更有价值。最后分享一个小技巧遇到HAVING相关的复杂SQL我习惯先把它拆成两步来验证。第一步先跑一个不带HAVING的GROUP BY查询看看每个分组算出来的值是否合理第二步再手动在结果集里做一次HAVING过滤确认最终输出的分组确实符合预期。这样既能快速定位问题是出在分组还是出在过滤也能对数据分布建立直觉。你可能觉得这一步多余但在我处理线上疑难慢查询的时候这个笨办法救过我很多次。
MySQL HAVING子句详解：与WHERE的区别、执行顺序及优化实践
写这篇文章的起因很实在前几天帮团队做代码评审一位同事写了一条统计SQL大意是查出销售金额超过一万的订单明细结果他把SUM(amount) 10000直接写进了WHERE子句数据库当场就报错“Invalid use of group function”。他愣了半天没想明白为什么同样的条件放在HAVING里就能跑通。这个问题其实特别典型也是MySQL里HAVING子句最容易被卡住的地方。HAVING是MySQL的SELECT七大子句里非常特殊的一个。它和WHERE长得像功能也像但作用时机完全不同。很多人把SQL当英语读觉得HAVING就是“又一个过滤条件”结果一遇到聚合函数就翻车。这篇文章我会把HAVING从执行时机、语法限制、与WHERE的本质区别到常见坑点和优化思路全部拆开揉碎讲清楚。不管你是刚开始写SQL的新手还是被慢查询折磨的运维老手这篇文章都能帮你在HAVING这里少踩几个坑。1. 理解having的前提先看select子句的执行链路单独背HAVING的语法没有意义它所有的“疑难”都出在“它在什么时候执行”这件事上。MySQL的SELECT语句虽然书写顺序是SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ... LIMIT但逻辑执行顺序完全不是这样。1.1 七大select子句的逻辑执行顺序一条完整的带聚合的查询内部执行顺序大致是这样的FROM确定数据源加载表如果有JOIN就在这一步做连接。WHERE对FROM产出的行做逐行过滤此时聚合函数还没登场。GROUP BY把过滤后的行按指定列分组。HAVING对分组后的结果做过滤此时聚合函数可以出场了。SELECT计算并输出最终要返回的列包括表达式、别名等。DISTINCT对结果去重如果写了的话。ORDER BY对最终结果排序。LIMIT限制返回行数。你可以把整个流程想象成一条流水线FROM是原料入库WHERE是第一道粗筛把不合规的原始行直接扔掉GROUP BY把留下的行装进不同的箱子HAVING是对整箱货物做质检——不合格的整箱淘汰最后才轮到SELECT打标签、ORDER BY排队、LIMIT限流。这个类比看起来简单但它能解决一个很大的认知误区WHERE看不到聚合结果因为它在分组之前就跑完了HAVING看不到原始行因为它处理的已经是分组后的箱子。1.2 执行顺序对having的三个直接影响理解了执行链路很多规则就顺理成章了。第一WHERE里不允许出现聚合函数。因为聚合是分组阶段才做的事情第一道粗筛工序的机器还没有聚合能力你让它做SUM()它自然报错。必须把含聚合函数的过滤条件放到HAVING。第二SELECT里的别名在HAVING阶段通常不可用。因为别名是在SELECT阶段才定义的而HAVING先于SELECT执行。MySQL确实对HAVING引用别名做了一些放宽后面会专门讲但其他数据库比如SQL Server在这一点上非常严格跨数据库写SQL的人很容易踩坑。第三WHERE过滤掉的原始行不会进入GROUP BY也就不会影响聚合结果而HAVING是在聚合之后过滤它不会减少聚合的计算量只影响最终输出。这一点直接决定了一条SQL是先用WHERE还是先用HAVING后面性能优化那节我会展开说。2. having与where表面相似本质不同的过滤双雄很多MySQL教程一讲到HAVING就是一句“为分组过滤条件使用”但没有解释为什么需要这样一个看似重复的子句。在我看来HAVING和WHERE的关系像是面试中的“简历初筛”和“终面”初筛先筛掉明显不匹配的人终面再根据综合素质判断是否录用。两道工序缺一不可因为它们的判断依据完全不同。2.1 一张表说清where与having的核心区别对比维度WHEREHAVING执行时机GROUP BY之前GROUP BY之后过滤对象原始行分组后的组能否使用聚合函数不能可以能否引用SELECT别名通常不能MySQL中可以其他数据库严格受限对性能的影响减少分组数据量通常可用索引优化在聚合完成后过滤无法通过索引过滤与GROUP BY的关系可以不写GROUP BY单独使用常与GROUP BY配合但也可以单独使用这张表的核心就一句话WHERE在分组前过滤行HAVING在分组后过滤组。2.2 一个真实例子查找平均工资超过8000的部门假设有一张员工表employeesiddept_idsalary110120002106000320900042080005305000现在要查“平均工资超过8000的部门”正确的写法是SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id HAVING AVG(salary) 8000;结果只有部门10平均9000满足条件。这里AVG(salary)必须放在HAVING中因为平均值是分组之后才计算出来的WHERE阶段根本没有这个值。如果错误地写成SELECT dept_id, AVG(salary) AS avg_salary FROM employees WHERE AVG(salary) 8000 GROUP BY dept_id;MySQL会直接报错Invalid use of group function。原因在前面已经说了——WHERE执行时聚合函数还没开始计算它没有能力对聚合结果做判断。反过来还有一种情况如果需求是“先排除工资低于6000的员工再统计各部门的平均工资”那就必须用WHERE先过滤分组时只看到符合条件的行聚合结果自然也就不同SELECT dept_id, AVG(salary) AS avg_salary FROM employees WHERE salary 6000 GROUP BY dept_id HAVING AVG(salary) 8000;这个例子的意义在于WHERE和HAVING不是二选一的关系而是同一套逻辑里先后配合的两道关卡。前者过滤参与者后者过滤结果。3. having的实操要点能写什么、不能写什么、怎么写最稳HAVING的语法本身很简单真正让人头疼的是它里面到底能放什么条件。我见过不少同事在HAVING里写了非聚合列、写了别名、甚至写了DISTINCT结果每种写法都有自己的一套规则。这一节把这些问题全部整理出来。3.1 having里能放的条件类型HAVING的条件分为三类第一类是聚合函数条件这是HAVING的核心用途。常见的包括SUM()、COUNT()、AVG()、MAX()、MIN()、GROUP_CONCAT()等例如-- 只保留订单数量大于3的客户 SELECT customer_id, COUNT(*) AS order_cnt FROM orders GROUP BY customer_id HAVING COUNT(*) 3; -- 只保留总金额在1000到5000之间的分组 SELECT customer_id, SUM(amount) AS total_amount FROM orders GROUP BY customer_id HAVING SUM(amount) BETWEEN 1000 AND 5000;第二类是分组列条件。如果某列参与了GROUP BY它也可以在HAVING中出现例如SELECT dept_id, COUNT(*) AS emp_cnt FROM employees GROUP BY dept_id HAVING dept_id IN (10, 20, 30);不过这种情况我个人更推荐用WHERE去做因为分组列的条件在分组前就能过滤用WHERE性能更好语义也更清晰。第三类是非分组列直接条件这种写法在MySQL里是允许的但结果可能不同于直觉下面单独说。3.2 非聚合列直接出现在having里的坑先看这条SQLSELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id HAVING salary 8000;salary既不是GROUP BY的列也没有被聚合函数包裹。在MySQL中这条SQL大概率能跑通但它返回的结果可能是不确定的。原因在于分组后每个组里有多个salary值MySQL到底取哪一个去和历史条件比较完全依赖于执行计划和存储引擎的内部行为不可控。SQL标准要求HAVING中出现的非聚合列必须出现在GROUP BY中MySQL之所以允许是为了兼容某些历史场景。但从实践角度这种写法基本等于埋雷。如果确实要对非聚合列做条件判断要么把它加入GROUP BY要么用聚合函数包一层要么在WHERE阶段就过滤掉。3.3 having引用别名的兼容性陷阱MySQL在HAVING中允许引用SELECT中定义的别名例如SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id HAVING avg_salary 8000;这在MySQL里可以正常工作因为MySQL对HAVING的解析会做一次别名替换。但在SQL Server、Oracle等数据库中这种写法会直接报错Invalid column name avg_salary因为逻辑执行顺序中HAVING先于SELECT别名还不存在。所以如果你写的是跨数据库兼容的SQL务必不要在HAVING里用别名老老实实写完整聚合表达式。就算是只在MySQL中使用也建议正式代码里保持完整写法因为可读性和可移植性都会被拉高。3.4 having与distinct的冷门组合有些场景需要在分组后对某个字段去重再统计比如统计每个客户购买过的商品种类数这时候HAVING可以结合COUNT(DISTINCT ...)SELECT customer_id, COUNT(DISTINCT product_id) AS product_kind FROM orders GROUP BY customer_id HAVING COUNT(DISTINCT product_id) 5;还有一种少见的情况HAVING本身就带DISTINCT比如SELECT customer_id, COUNT(*) AS order_cnt FROM orders GROUP BY customer_id HAVING COUNT(DISTINCT order_date) 3;这表示筛出“下过至少4天订单”的客户而不是“下过4单”的客户。这个场景在统计活跃用户时非常实用但很多人想不到HAVING里还能再嵌套一层DISTINCT。唯一的提醒是COUNT(DISTINCT)在大表上性能开销很高能用小表先缩小范围的话尽量别一股脑全表跑。4. 疑难点逐个击破从分组、去重到join的复杂组合写HAVING的坑往往不是语法本身而是它和GROUP BY、JOIN、NULL值这些机制组合在一起时产生的各种行为。这一节我挑几个最常见的疑难点展开讲。4.1 group by与having的配合细节GROUP BY和HAVING是一对搭档但这里的细节很容易被忽略。第一GROUP BY会把NULL值单独分一组。比如统计员工表里各部门人数如果dept_id有NULL结果里会多出一行dept_id NULL的分组。如果你不想要这个分组可以用WHERE dept_id IS NOT NULL先行过滤或者用HAVING dept_id IS NOT NULL事后过滤。两者都可但前者通常性能更好。第二GROUP BY之后HAVING里可以用GROUP_CONCAT做一些很巧妙的判断。比如查“一个订单里包含商品A和商品B的订单号”SELECT order_id FROM order_items GROUP BY order_id HAVING GROUP_CONCAT(product_id ORDER BY product_id) LIKE %A%B%;这种写法虽然能跑但可读性稍差更常见的场景是统计某个分组里满足特定条件的记录条数再用HAVING过滤比如SELECT order_id FROM order_items WHERE product_id IN (A, B) GROUP BY order_id HAVING COUNT(DISTINCT product_id) 2;这个写法才是“同时包含A和B”的稳妥解法——先过滤出只和A、B相关的行再分组判断去重商品数是否为2等于2说明两个都有。第三GROUP BY和HAVING的过滤顺序直接决定了聚合结果是否包含被淘汰的数据。WHERE先过滤掉的数据不参与聚合HAVING过滤掉的是已经算完聚合结果的分组。这两者在统计含义上的差别比性能上的差别更值得注意。4.2 having在海量数据下的性能隐患很多人的认知是HAVING写得很爽反正它能过滤分组那就把条件全扔给它。这其实是个性能大坑。WHERE能在数据进入分组前减少数据量而且往往能利用索引直接定位到符合条件的行HAVING必须等GROUP BY把所有行分好组、把所有聚合函数算完才能逐组做判断。这意味着一行HAVING条件背后是整个表的分组计算代价。举个例子一张一千万行的订单表要查“下单次数超过10次且总金额超过一万的用户”。如果所有过滤都放在HAVING里MySQL就得先按user_id把一千万行全部分组再计算每个组的COUNT(*)和SUM(amount)最后才过滤。如果在WHERE阶段先加一个order_date之类的范围条件把数据量缩小到一百万行分组的代价直接小一个数量级。所以我的习惯是能用WHERE过滤的绝不放HAVINGHAVING里只放那些必须依赖聚合结果的条件。比如上面的例子合理写法是SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amount FROM orders WHERE order_date 2024-01-01 GROUP BY user_id HAVING COUNT(*) 10 AND SUM(amount) 10000;order_date的范围过滤走索引进入分组的行数变少聚合计算量大幅下降HAVING只负责最后的门槛判断。4.3 having与join组合时的常见误区多表JOIN之后再分组过滤很多人分不清楚WHERE该放哪、HAVING该放哪。核心规则不变过滤连接前原始行的条件放WHERE过滤分组聚合结果的条件放HAVING。假设有users表和orders表要查“2024年之后下单用户中平均客单价超过500元的城市”SELECT u.city, AVG(o.amount) AS avg_amount FROM users u JOIN orders o ON u.id o.user_id WHERE o.order_date 2024-01-01 GROUP BY u.city HAVING AVG(o.amount) 500;WHERE o.order_date 2024-01-01是在JOIN之后、GROUP BY之前执行的它先把不符合时间要求的订单行淘汰掉HAVING AVG(o.amount) 500是对每个城市分组做完平均值计算后再筛选。这两者的位置一旦写反统计口径和性能都会出问题。另外JOIN时如果使用LEFT JOIN关联不到匹配行的列会产生NULL值这些NULL值在GROUP BY时会被分到同一个组HAVING中如果用COUNT(orders.id)统计不会把NULL计入但用COUNT(*)会把NULL行也算进去。这一点非常阴险——明明是同一条SQL逻辑换一个聚合函数结果就变了。4.4 having别名的极限操作与分组序号MySQL还支持在HAVING中使用GROUP BY的序号比如SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY 1 HAVING AVG(salary) 8000;这里的GROUP BY 1表示按SELECT列表的第1列即dept_id分组。这种写法虽然节省了几个字符但可读性极差一旦SELECT列顺序调整结果就可能出错。在团队协作的正式代码里我一律不推荐用序号分组更不用说在HAVING里依赖于这种序号关系了。规范的第一优先级始终是可读性和可维护性。5. 常见问题与排查技巧实录写HAVING踩坑不可怕可怕的是踩了坑还不知道问题出在哪。这一节我把我实际遇到过的几类问题整理成了速查表每一类都附上排查思路和解决方向。5.1 having高频报错与解决方案速查表报错信息原因分析解决方案Invalid use of group function在WHERE中使用了聚合函数把聚合函数条件移到HAVINGUnknown column 别名 in having clause在HAVING中引用了SELECT别名但数据库解析顺序不允许改成完整聚合表达式或确认MySQL版本是否支持再使用Column xxx is invalid in the select list ... not contained in either an aggregate function or the GROUP BY clause在MySQL 5.7开启了only_full_group_by模式下SELECT中出现了非聚合非分组列调整SELECT列让它们要么被聚合要么出现在GROUP BY中结果里多出一个NULL分组GROUP BY列存在NULL值在WHERE阶段加列 IS NOT NULL过滤查询结果与预期不符HAVING过滤后数据变少HAVING中使用了非分组列条件MySQL取了某个不确定的值使用聚合函数包裹该列或把条件移到WHEREHAVING执行慢全表扫描GROUP BY前没有缩小数据量在WHERE增加范围条件尽量走索引5.2 一条真实排查记录orders 表现身说法有一次排查一个线上报表慢查询SQL大概是这样的SELECT seller_id, COUNT(*) AS order_cnt FROM orders GROUP BY seller_id HAVING order_cnt 100 ORDER BY order_cnt DESC LIMIT 10;这条SQL在数据量小的时候跑得飞快但数据量到了千万级之后每次查询都要等好几秒。原因是HAVING order_cnt 100里引用了SELECT别名——MySQL允许这种做法但它本质上必须等GROUP BY把全量数据分组并计算出COUNT(*)之后才能拿着结果去过滤。也就是说哪怕最终只需要10个卖家MySQL依然把几千万行全部聚合了一遍。优化思路有两个方向。方向一是把过滤条件下沉到子查询里但这里HAVING本身已经是对聚合结果的过滤没法再下沉到WHERE。真正可行的做法是给表加合适的索引减少GROUP BY的排序成本或者在应用层做缓存把低频全量报表换成预计算任务。方向二是如果业务允许可以先用一个WHERE条件缩小时间窗口比如只看近30天的数据这样进入GROUP BY的行数大大减少。那次排查给我的教训是HAVING里的别名看着方便但一条SQL里如果HAVING条件和ORDER BY都依赖别名执行计划往往不会有多聪明优化的突破口经常在源头数据量控制上而不是在HAVING写法本身上。5.3 写having容易忽略的三个细节第一HAVING在没有GROUP BY的时候也可以单独使用。这种情况下整张表会被当成一个大组HAVING相当于对整个表的聚合结果做过滤。比如SELECT COUNT(*) FROM employees HAVING COUNT(*) 100;这条SQL合法意义是“如果公司员工超过100人就返回总人数否则返回空结果集”。但写成这样可读性并不高建议用子查询或直接对结果做判断。第二HAVING的滞后性会让你忽略真实的数据量成本。我在实际开发中见过有人习惯把所有过滤条件都塞进HAVING觉得“反正SQL能跑就行”结果一到线上数据量上来就崩。永远记住能在WHERE里过滤掉的绝不留给HAVING。第三也是很多规范文档里不会提的HAVING和ORDER BY的执行顺序在MySQL中同样是HAVING先于ORDER BY。所以如果ORDER BY里引用了别名那是在SELECT阶段之后才能解析的内容不会反过来影响HAVING的过滤范围。搞清楚这个顺序你在调试“为什么排序结果不对”的时候能少走很多弯路。6. 从having延伸出去面试题与SQL优化直觉HAVING是MySQL面试里的高频考点也是很多人从“会写SQL”到“理解SQL”之间的一道分水岭。这一节把常见的面试题做一个梳理同时分享两个我总结的优化直觉。6.1 面试常问的几个having问题第一题“WHERE和HAVING有什么区别”回答框架就三条执行时机不同一个在GROUP BY前、一个在后能否使用聚合函数不同WHERE不能、HAVING可以过滤对象不同一个过滤行、一个过滤分组。再补一句性能上的直觉能用WHERE的优先用WHERE因为它减少的是进入分组的源数据量。第二题“HAVING里能不能用SELECT的别名”在MySQL里可以但不建议依赖在SQL标准和其他主流数据库中通常不行。回答时最好能说出原因——逻辑执行顺序中HAVING先于SELECT执行别名还没有被定义。第三题“一条SQL的执行顺序是什么”除了标准的八步链路之外能答出WHERE聚合不行、HAVING引用别名不行这类细节才算真正理解。面试官往往不是要你背全套顺序而是看你能不能用它解释实际遇到的问题。第四题“COUNT(*)和COUNT(column)在HAVING里的区别”COUNT(*)统计所有行包括NULLCOUNT(column)会跳过该列为NULL的行。这个细节在LEFT JOIN场景下特别容易踩坑具体例子前面已经说过。6.2 实用的优化直觉优先缩小数据集我写SQL的准则之一是做任何操作之前先问自己“这个阶段我处理了多少行”一个好的SQL是逐步缩小数据集的WHERE缩小到可接受的范围GROUP BY在这个范围内做聚合HAVING只过滤少数不符合条件的组最后ORDER BY和LIMIT只处理极少量数据。如果把过滤全部放在HAVING等于把分组聚合当成全表操作来完成性能自然是灾难。所以优化HAVING相关查询最有效的不是去调整HAVING本身的写法而是回头看WHERE是否漏掉了可以提前过滤的条件以及GROUP BY能否借助索引避免文件排序。经常是加一个合适的索引原来慢如蜗牛的GROUP BY HAVING查询立刻变得飞快因为分组操作直接通过索引的有序性完成了连排序临时文件都省了。6.3 从having到完整查询设计的小结HAVING不是一个孤立的关键字它是整个SELECT查询链条的产物。理解了它的执行时机就理解了WHERE、GROUP BY、聚合函数、别名、索引优化之间的相互关系。很多MySQL高手的功力并不是体现在背了多少语法而是看到一个慢查询能凭直觉判断出瓶颈是在WHERE的索引使用还是在GROUP BY的分组成本还是在HAVING的滞后过滤。这种直觉说白了就是对查询执行顺序的内化。在我自己写SQL的习惯里最后一个动作永远是回过头检查一遍每个子句的执行位置这个条件真的不能下沉到WHERE吗这个别名会不会影响其他数据库的兼容性分组前的数据量是不是已经被压缩到最小了这些审视比任何语法记忆都更有价值。最后分享一个小技巧遇到HAVING相关的复杂SQL我习惯先把它拆成两步来验证。第一步先跑一个不带HAVING的GROUP BY查询看看每个分组算出来的值是否合理第二步再手动在结果集里做一次HAVING过滤确认最终输出的分组确实符合预期。这样既能快速定位问题是出在分组还是出在过滤也能对数据分布建立直觉。你可能觉得这一步多余但在我处理线上疑难慢查询的时候这个笨办法救过我很多次。
