WHERE中不能使用COUNT()等聚合函数，因为执行到WHERE阶段时尚未分组，聚合值不存在；正确做法是先用WHERE过滤原始字段，再GROUP BY，最后用HAVING过滤聚合结果。
WHERE里写COUNT()直接报错，不是逻辑错而是语法错
执行到WHERE阶段时，数据库连“组”都还没分，COUNT(*)、SUM(amount)这些聚合值根本不存在。你让它判断“这一行的订单数是不是大于5”，它只能回你一句“这行哪来的订单数？”。典型报错信息是：ERROR 1111: Invalid use of group function 或 aggregate functions are not allowed in WHERE。
-
WHERE能用的只有原始表字段，比如status、created_at、user_id -
WHERE里出现任何聚合函数（COUNT、AVG、MAX等）都会被数据库当场拒绝 - MySQL 5.7+ 在宽松模式下可能不报错，但结果不可靠；换到 PostgreSQL 或 SQL Server 立刻失败
HAVING条件误塞进WHERE，实际是把过滤时机搞反了
即使语法侥幸通过（比如某些MySQL配置），逻辑也大概率错：你想筛“2024年下单超10次的客户”，却把时间条件放在HAVING里，或者把聚合条件硬塞进WHERE，本质是让数据库先对全量数据分组，再筛——性能差、内存涨、索引失效。
- ✅ 正确做法：
WHERE order_date >= '2024-01-01'→ 先筛掉旧数据 → 再GROUP BY customer_id→ 最后HAVING COUNT(*) > 10 - ❌ 错误做法：
HAVING order_date >= '2024-01-01'→ 报错，因为order_date没出现在GROUP BY中，HAVING看不见它 - ⚠️ 更隐蔽的错：
WHERE COUNT(*) > 10写法根本跑不通；但若换成HAVING COUNT(*) > 10却漏了WHERE时间条件，查出来的“超10单客户”可能包含2010年的数据
子查询里直接写HAVING会语法报错
标准 SQL 不允许在子查询内部单独使用HAVING。比如想查“订单数超5的客户的所有订单”，不能在IN子句里直接跟GROUP BY ... HAVING，否则报syntax error at or near 'HAVING'。
- 正确结构必须把聚合逻辑封装成独立子查询：
(SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) > 5) - 或改用 CTE：
WITH t AS (SELECT ... GROUP BY ... HAVING ...)，再在外层引用 - MySQL 5.7 及更早不支持 CTE，只能用派生表（带
AS t的子查询） -
HAVING里不能用SELECT定义的别名，如HAVING total_amt > 1000在 PostgreSQL 中报错，得写HAVING SUM(amount) > 1000
HAVING位置写错，语句直接无法解析
HAVING不是可随意挪动的装饰词，它有严格位置要求：必须紧跟在GROUP BY之后、ORDER BY之前。写在WHERE前面，或ORDER BY后面，数据库会直接拒绝执行。
- SQL 执行顺序固定为：
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT -
HAVING依赖GROUP BY产出的分组上下文，前置或后置都会导致解析失败 - 某些 MySQL 版本容忍
HAVING无GROUP BY（整张表当一个组），但这属于方言行为，跨库迁移时极易出问题
