HAVING 是唯一能对 COUNT()、SUM() 等聚合结果做条件过滤的地方；WHERE 在分组前执行，无法访问聚合值，写 WHERE COUNT(*) > 5 会报错；正确做法是 GROUP BY 后用 HAVING 筛选，原始数据过滤仍放 WHERE。
WHERE 和 HAVING 到底谁该管“数量”
查“超过某数量的记录”，本质是先分组、再统计、最后筛选——HAVING 是唯一能对 COUNT()、SUM() 这类聚合结果做条件过滤的地方。WHERE 在分组前就执行，根本看不到每组有多少条，硬写 WHERE COUNT(*) > 5 会直接报错：ERROR: aggregate functions are not allowed in WHERE。
常见错误现象：把条件写在 WHERE 里，SQL 执行失败；或者误以为加了 GROUP BY 就能用 WHERE 筛聚合值，结果逻辑完全不对。
-
HAVING必须跟在GROUP BY后面（没分组时也能用，但意义有限） - 想查“每个部门人数 > 3”，必须写
GROUP BY dept_id HAVING COUNT(*) > 3，不能把COUNT(*) > 3塞进WHERE - 如果还要限制原始数据（比如只看 status = 'active' 的人），这部分条件仍放
WHERE，它会在分组前先过滤掉无关行，提升性能
HAVING 中怎么写“超过 10 条”的条件
最直白的写法就是 HAVING COUNT(*) > 10，但要注意几个实际细节：
- 用
COUNT(*)统计所有行（包括NULL），用COUNT(列名)会忽略该列值为NULL的行——如果业务上“空值不算有效记录”，就得选后者 - 想查“订单数 ≥ 5 且总金额 > 1000 的用户”，可以同时写多个条件：
HAVING COUNT(*) >= 5 AND SUM(amount) > 1000 - MySQL 8.0+ 和 PostgreSQL 支持在
HAVING里引用SELECT中的别名（如SELECT COUNT(*) AS cnt ... HAVING cnt > 10），但 SQLite 和旧版 MySQL 不支持，建议直接重复表达式，避免兼容性问题
不加 GROUP BY 时 HAVING 能干什么
单独用 HAVING 不加 GROUP BY 是合法语法，此时整张表被当成“一个组”，HAVING 就相当于对全表聚合结果做开关判断。
典型场景：检查某张配置表是否为空，或确认是否存在满足全局条件的数据。
-
SELECT 1 FROM users HAVING COUNT(*) > 1000—— 返回一行1表示用户数超千，否则无结果 - 比
SELECT COUNT(*) FROM users再用程序判断更轻量，尤其在只需要“是/否”信号时 - 注意：这种写法不能返回原始记录，只能用于存在性校验或简单计数判断
ORDER BY 和 LIMIT 放在 HAVING 后面才生效
SQL 执行顺序是 WHERE → GROUP BY → HAVING → ORDER BY → LIMIT，所以排序和截取必须放在 HAVING 之后，否则会漏掉真正要的结果。
例如查“订单数最多的前 3 个客户”：
SELECT customer_id, COUNT(*) AS order_cnt FROM orders GROUP BY customer_id HAVING COUNT(*) >= 5 ORDER BY order_cnt DESC LIMIT 3
容易踩的坑：
- 把
LIMIT 3错放在HAVING前面，会导致先截取 3 条再分组，结果完全错误 -
ORDER BY如果引用的是聚合字段（如order_cnt），必须确保它出现在SELECT列表中，否则某些数据库（如 MySQL 严格模式）会报错：Unknown column 'order_cnt' in 'order clause'
复杂点在于：HAVING 的条件本身可能依赖多层嵌套或子查询，一旦涉及性能敏感场景，得先确认分组键的选择性——低区分度的字段（比如只有 2–3 个值的 status）会让分组后数据倾斜，HAVING 过滤效率反而下降。
