WHERE中不能使用COUNT(*)或SUM(price)等聚合函数，因其执行早于GROUP BY和聚合计算；正确做法是用HAVING过滤聚合结果，或通过子查询、窗口函数等方式绕过限制。
WHERE子句里写COUNT(*)或SUM(price)一定会报错，不是数据库太严格，而是这个值在WHERE执行时根本不存在——它还没被算出来。
WHERE阶段聚合值压根没生成
SQL真实执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着WHERE看到的只是原始表的一行行数据，连“按user_id分组”都还没发生，更别说每组有多少条记录了。
-
WHERE COUNT(*) > 5在PostgreSQL中报aggregate functions are not allowed in WHERE，MySQL 8.0+ 报Invalid use of group function - 哪怕表只有一行，
WHERE COUNT(*) = 1照样非法——问题不在数值对不对，而在于语法解析阶段就被拒绝 -
SELECT COUNT(*) AS cnt FROM t之后写WHERE cnt > 5也无效，WHERE看不到SELECT里的别名
HAVING才是聚合后过滤的唯一合法位置
HAVING运行在GROUP BY完成之后，此时各组的COUNT(*)、AVG(price)等均已计算完毕，才能安全使用。
-
HAVING必须和GROUP BY成对出现；单独写HAVING COUNT(*) > 3不带GROUP BY，MySQL 5.7+ 默认报错 -
HAVING cnt > 3（引用SELECT中定义的别名）在MySQL/PostgreSQL中可行，但SQLite或旧版MySQL可能不认，建议优先复写为HAVING COUNT(*) > 3 -
HAVING只能引用GROUP BY中的列、聚合表达式、常量，不能用未分组也未聚合的普通字段，比如HAVING user_name = 'Alice'会报错
绕开限制的三种实操写法
当业务只需要“满足聚合条件的ID列表”，又不想最终结果带统计列，就得换结构：
- 子查询方式：
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 t.cnt >= 3—— 窗口函数不能直出WHERE，必须先出现在派生表或SELECT中 - 标量子查询（慎用）：
SELECT DISTINCT user_id FROM orders o1 WHERE (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) >= 3—— 大表易触发N+1，性能通常较差
性能坑：把WHERE条件错塞进HAVING
把本该下推的行级条件硬塞进HAVING，会让数据库多做大量无用聚合计算。
-
WHERE status = 'paid'放对位置 → 扫描前就过滤掉无效订单，分组输入行数大幅减少 - 错写成
HAVING status = 'paid'→ 先对全部订单（含cancelled）分组，再扔掉90%的组，内存暴涨、超时、OOM风险陡增 - 尤其当分组键基数高（如按
user_id分上百万组），这种错误会直接拖垮查询
最容易被忽略的是：错放条件不只是语法问题，更是执行计划层面的失控点——数据库不会警告你“这里慢”，它只会默默分配更多内存、跑更久、然后失败。
