WHERE不能使用COUNT(*)等聚合函数，因其执行早于聚合计算；正确做法是将聚合条件移至HAVING，但必须配合GROUP BY，且HAVING只能引用分组字段或聚合表达式。
WHERE不能用COUNT(*)这类聚合函数，否则直接报错
执行顺序决定了WHERE只能看到原始表字段，COUNT(*)、SUM(amount)这些值还没算出来。写WHERE COUNT(*) > 5或WHERE AVG(salary) > 8000会立刻触发语法错误，比如MySQL报Unknown column 'COUNT(*)' in 'where clause'，PostgreSQL提示GROUP BY clause is required before using aggregate functions。
正确做法是把聚合条件挪到HAVING里，但前提是已加GROUP BY——没分组就用HAVING，多数数据库直接拒绝。
HAVING必须跟GROUP BY一起出现，且只能引用分组字段或聚合表达式
HAVING不是独立过滤器，它依赖分组结果存在。单独写SELECT * FROM orders HAVING amount > 1000会报错，因为没分组，也就没有“组”可筛。
常见错误是把非分组列塞进HAVING，比如SELECT dept, AVG(salary) FROM emp GROUP BY dept HAVING name = 'Alice'——name既没在GROUP BY里，也不是聚合值，直接失败。
-
HAVING允许用COUNT(*)、SUM(amount)、AVG(price)等，但别名（如AS total）在PostgreSQL和SQL Server里不可用，得写原表达式 - MySQL允许
HAVING total > 5000（依赖别名），但跨库迁移时极易出问题 - 空值要显式处理：
HAVING AVG(score) > 80会跳过全为NULL的组，稳妥写法是HAVING AVG(score) IS NOT NULL AND AVG(score) > 80
WHERE条件误塞进HAVING会导致性能明显下降
想查「部门ID为1且该部门员工数大于2」，如果写成：
SELECT dept_id, COUNT(*) FROM employees GROUP BY dept_id HAVING dept_id = 1 AND COUNT(*) > 2;
数据库会先对全表分组，再丢掉除dept_id = 1外的所有组——白算一堆聚合。应该写成：
SELECT dept_id, COUNT(*) FROM employees WHERE dept_id = 1 GROUP BY dept_id HAVING COUNT(*) > 2;
WHERE先筛出行，再分组，数据量小，快得多。
- 所有能用
WHERE过滤的单行属性（如status、created_at、dept_id），别塞进HAVING里 -
WHERE支持索引，HAVING只在内存里过滤，无法走索引 - 没
GROUP BY时硬用HAVING行为不可靠：MySQL 5.7+默认允许，但整张表被当作一个组处理，表为空时HAVING COUNT(*) > 0返回空而非报错，隐蔽难排查
混用WHERE和HAVING时，执行顺序决定逻辑含义
写WHERE status = 'active' GROUP BY dept HAVING AVG(salary) > 5000，意思是：先剔除非活跃员工，再按部门算平均工资，最后筛出均薪超5000的部门。
这个顺序不能颠倒——WHERE减少输入分组的数据量，直接影响性能；HAVING只在分组后内存里过滤。
- 如果只是想判断全表聚合结果（如“总销售额是否超百万”），优先用子查询：
SELECT * FROM (SELECT SUM(amount) AS total FROM orders) t WHERE total > 1000000 -
GROUP BY ()或GROUP BY 1虽可绕过语法限制，但可读性差，且不同数据库兼容性不一 - 别名只在
SELECT阶段绑定，所以只有HAVING和之后的子句能用，WHERE一定报错
实际写查询时，最常被忽略的是：HAVING里出现的非聚合字段（比如dept_id），只要它也在GROUP BY列表中，几乎总该优先移到WHERE里——除非你真需要先分组再筛组。
