HAVING条件的基本作用
在写SQL查询时，我们经常需要对分组后的数据进行筛选。这时候WHERE已经不够用了，就得靠HAVING出场。比如统计每个部门的平均工资，只显示平均工资超过8000的部门，就得用HAVING。
别把WHERE的事儿交给HAVING
很多人习惯性地把所有筛选都塞进HAVING里，这是最常见的性能坑。HAVING是在GROUP BY之后执行的，数据量可能已经很大了。而WHERE是在分组前过滤，能大大减少参与分组的数据量。
比如要查“技术部”中平均薪资大于7000的项目组：
SELECT project, AVG(salary)
FROM employees
WHERE department = '技术部' -- 先缩小范围
GROUP BY project
HAVING AVG(salary) > 7000;如果把department的条件放到HAVING里，数据库就得先对全表分组，再筛选，慢得多。
避免在HAVING里用复杂函数
有些人在HAVING里写一堆计算，比如HAVING YEAR(create_time) = 2023，这种函数会导致索引失效。更好的做法是提前在WHERE里处理好时间范围。
比如统计去年销售额超10万的客户：
SELECT customer_id, SUM(amount)
FROM orders
WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01'
GROUP BY customer_id
HAVING SUM(amount) > 100000;合理使用索引辅助分组
GROUP BY字段如果有索引，分组会快很多。虽然这不直接改HAVING，但整体查询效率上去了。比如按user_id分组，就确保user_id有索引。
能提前过滤的，别等到HAVING
有个同事曾经写了个报表SQL，跑一次要30秒。一看，他在HAVING里判断COUNT(*) > 5，但其实大部分用户根本没几条记录。改成先用子查询或临时表把记录数多的用户筛出来，再分组统计，时间降到3秒内。
少用OR，多拆成多个查询
HAVING里的OR会让优化器很难选择执行计划。如果条件差异大，不如拆成两个查询用UNION ALL合并。虽然代码长点，但速度可能翻倍。
监控执行计划才是王道
最实在的办法是看执行计划。用EXPLAIN看看你的HAVING是不是导致了全表扫描或者临时表排序。有时候加个ORDER BY NULL能关掉不必要的排序，提升速度。
优化不是靠背规则，而是看实际执行情况。公司那个订单统计页面卡顿，调了半天发现是HAVING里套了子查询，改成JOIN后流畅多了。