HAVING用于过滤分组后的结果集，只能在GROUP BY之后使用，可引用聚合函数和SELECT别名；WHERE则在分组前执行，仅能使用原始字段。
HAVING 是用来过滤“组”的，不是过滤“行”
它只在
之后生效，作用对象是分组聚合后的结果集。比如你算出每个客户的订单总数（
），想只留下订单数 > 5 的客户——这个条件不能写在
里，因为
还没看到聚合值。
在分组前执行，只能用原始字段（如
）
在分组后执行，可以安全使用
、
、
等，也能引用
中定义的别名（如
）
如果误把聚合条件塞进
，MySQL 会直接报错：
必须和 GROUP BY 搭配，但 WHERE 可以先筛一遍
单独写
不报错，但逻辑上无意义（没有分组就没有“组”可滤）。实际中常和
配合：先用
减少数据量，再分组，最后用
精筛。
不加
直接全表分组，可能拖慢查询，尤其大表
中的字段只能是：
列 或 聚合表达式（或其别名），不能是未分组也未聚合的原始列（如写
会报错）
常见踩坑：别名能用，但仅限 HAVING 和 ORDER BY
很多人以为
里起了别名，
就能用——不行。
执行时别名还没生成。而
和
都在
之后，所以它们能认别名。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
错误写法：
→ 报错
也不建议在
里重复写聚合表达式（如
），虽然合法，但冗余且难维护
若需多层聚合判断（如“部门平均工资 > 公司平均工资”），得用子查询或窗口函数，
本身不支持跨组比较
性能敏感点：HAVING 无法利用索引，慎用于
大数据
量分组
是对内存中已分组的结果做扫描过滤，不走索引。当分组后仍有大量组（比如按用户ID分组，千万级用户），
条件会成为瓶颈。
优先考虑能否把条件前移到
（例如：只分析近30天数据，就加
）
避免在
中用函数包裹字段（如
），这会让优化器更难估算
如果只是要取 Top N 分组（如销量前10的品类），记得加
，否则 MySQL 可能物化全部分组再过滤
真正容易被忽略的是执行顺序：不是“写了 HAVING 就一定慢”，而是它天然发生在分组之后，意味着所有分组计算都已完成。哪怕你只想留 1 个组，MySQL 仍会先算出 10 万个组的聚合值，再用
剔掉其余 99999 个——这个代价，在设计查询时就得心里有数。
GROUP BYCOUNT(*)WHEREWHEREWHEREorder_date > '2024-01-01'HAVINGCOUNT()SUM()AVG()SELECTtotal_amountWHEREInvalid use of group functionHAVINGWHEREWHEREHAVINGSELECT customer_id, SUM(amount) AS total_amount
FROM orders
WHERE status = 'completed' -- 先剔除无效订单，提升性能
GROUP BY customer_id
HAVING total_amount > 1000; -- 再筛高价值客户WHEREHAVINGGROUP BYHAVING product_name = 'iPhone'SELECTWHEREWHEREHAVINGORDER BYSELECTSELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department
HAVING avg_salary > 50000 -- ✅ 正确：别名可用
ORDER BY avg_salary DESC;WHERE avg_salary > 50000Unknown column 'avg_salary'HAVINGHAVING AVG(salary) > 50000HAVINGHAVINGHAVINGWHEREWHERE create_time > DATE_SUB(NOW(), INTERVAL 30 DAY)HAVINGHAVING YEAR(order_date) = 2024ORDER BY ... LIMITHAVING