WHERE阶段无法使用聚合函数，因执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，聚合值尚未生成；HAVING才是聚合后过滤的合法位置，须与GROUP BY配合；优化应优先用WHERE过滤行级条件。
WHERE阶段聚合值根本不存在
你写 WHERE COUNT(*) > 5，数据库不是“算出来再比较”，而是直接在语法解析阶段就拒绝——PostgreSQL 报 aggregate functions are not allowed in WHERE，MySQL 8.0+ 报 Invalid use of group function。这不是语法写错了，是执行顺序决定了这个值此刻压根没生成。
SQL 真实执行顺序固定为：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着 WHERE 只看到原始表的一行行数据，连“按 user_id 分组”都还没发生，更别说每组有多少条记录了。
- 哪怕表只有一行，
WHERE COUNT(*) = 1依然非法——问题不在数值对不对，而在于这个值尚未计算 - 旧版 MySQL（如 5.6）可能不报错，但会把整张表当一个隐式组来算，导致
WHERE COUNT(*) > 1实际等价于“只要总行数 ≥ 2 就返回全表”，逻辑完全失控 -
WHERE也看不到SELECT中定义的别名，比如SELECT COUNT(*) AS cnt后写WHERE cnt > 5，照样报错
HAVING才是聚合后过滤的唯一合法位置
HAVING 是专为聚合结果设计的过滤子句，但它必须和 GROUP BY 成对出现。它运行在分组完成、各组聚合值已计算完毕之后，这时用 COUNT(*) 或 AVG(price) 才有意义。
- 没写
GROUP BY却用HAVING，MySQL 5.7+ 默认报错（语义模糊：对谁分组？），标准 SQL 不允许 -
HAVING COUNT(*) >= 3合法；HAVING cnt >= 3（引用SELECT中的别名）在 MySQL/PostgreSQL 中可行，但 SQLite 或旧版 MySQL 可能不认，建议优先复写表达式 - 性能上，
WHERE能大幅减少输入行数，HAVING只能筛组——像status = 'paid'这种行级条件必须放WHERE，硬塞进HAVING会让数据库先对百万行分组再扔掉 90% 的组，极易 OOM 或超时
绕开执行顺序的三种实操写法
如果业务只要“订单数 ≥ 3 的用户 ID”，又不想最终结果里带 COUNT(*) 列，就不能硬套 GROUP BY + HAVING，得换写法：
-
子查询方式：内层聚合，外层用
WHERE比较结果。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）：
COUNT(*) OVER (PARTITION BY user_id)给每行附上本用户的订单数，再在外层WHERE中使用。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—— 大表易变 N+1，性能通常较差
最容易被忽略的性能陷阱
错把条件放 HAVING 不只是语法问题，更是性能坑：它会让数据库多做大量无用聚合计算。尤其当分组键基数高（比如上千个不同 user_id），数据库得为每个组都算一遍 COUNT(*)，内存暴涨、查询超时、甚至 OOM。真正该下推的行级条件（如 created_at >= '2026-01-01'），一定要放在 WHERE，而不是靠加个 GROUP BY 就以为能“骗过”执行顺序。
