WHERE中写COUNT(*)或SUM(amount)一定报错，因SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，WHERE阶段尚未进行分组和聚合，聚合值根本不存在；HAVING是唯一合法使用聚合函数的位置，但必须与GROUP BY配合。
WHERE 里写 COUNT(*) 或 SUM(amount) 一定会报错，不是数据库太严格，而是这个位置根本“看不到”聚合值。
WHERE 阶段压根没算聚合值
SQL 执行顺序是固定的：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着：WHERE 处理的是原始表的每一行，此时连“组”都还没分，COUNT(*) 连结果都没有，更谈不上比较。
- 你写
WHERE COUNT(*) > 5，PostgreSQL 直接报aggregate functions are not allowed in WHERE，MySQL 报Invalid use of group function - 哪怕表只有一行，
WHERE COUNT(*) = 1同样非法——问题不在数值对不对，而在语法解析阶段就被拒绝 - 旧版 MySQL（如 5.6）可能不报错，但会把整张表当一个隐式组来算，行为不可控：比如
WHERE COUNT(*) > 1实际等价于“只要总行数 ≥ 2 就返回全表”，逻辑完全偏离预期
HAVING 是唯一合法位置，但必须配 GROUP BY
HAVING 是专为聚合结果设计的过滤子句，但它不能单独存在——它依赖 GROUP BY 完成分组和聚合计算后才有值可筛。
- 正确写法：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) >= 3 -
HAVING cnt >= 3（引用SELECT中的别名）在 MySQL/PostgreSQL 可行，但 SQLite 或旧版 MySQL 可能不认，建议优先复写表达式，比如HAVING COUNT(*) >= 3 - 没写
GROUP BY却用HAVING，MySQL 5.7+ 默认报错，因为语义模糊：对谁分组？标准 SQL 不允许
想绕过 GROUP BY 又要聚合筛选？用子查询或窗口函数
如果业务只要“订单数 ≥ 3 的用户 ID”，但不想最终结果里带 COUNT(*) 列，就不能硬套 GROUP BY + HAVING，得换写法：
- 子查询方式：
SELECT user_id FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t WHERE t.cnt >= 3—— 注意内层必须有别名t，否则 MySQL 8.0+/PostgreSQL 会报错 - 窗口函数方式（MySQL 8.0+/PostgreSQL）：
SELECT user_id FROM (SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders) t WHERE cnt >= 3—— 窗口函数不能直出WHERE，必须先在派生表或SELECT中生成 - 标量子查询也可行，比如：
WHERE (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) >= 3，但性能随数据量增长明显变差
真正容易被忽略的点是：WHERE 和 HAVING 的性能差异不是“慢一点”，而是“量级差”。把本该下推的条件（比如 status = 'paid'）错放 HAVING，数据库就得先对百万行分组、算完所有聚合，再扔掉 90% 的组——内存爆、超时、索引失效，一气呵成。
