where阶段聚合值根本不存在，因sql执行顺序为from→where→group by→having→select，where只处理原始行，未分组也未计算count(*)等值；必须用having（配合group by）、子查询或窗口函数替代。
WHERE阶段聚合值根本不存在
不是语法写错了，是数据库压根还没算出COUNT(*)或SUM(amount)的值。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也非法——问题不在数值对不对，而在这个值此刻根本没生成 - 旧版MySQL（如5.6）可能不报错，但会把整张表当一个隐式组来算，导致
WHERE COUNT(*) > 1实际等价于“只要总行数≥2就返回全表”，逻辑完全失控
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可能不认，建议优先复写表达式 - 能下推的条件别塞进
HAVING：status = 'paid'这种行级筛选必须放WHERE，否则数据库得先对百万行分组再扔掉90%的组，极易OOM或超时
没分组也要用聚合逻辑？绕开执行顺序的三种写法
如果业务只要“订单数≥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
大表易变N+1，性能通常较差。
最容易被忽略的性能陷阱
错把条件放HAVING不只是语法问题，它会让数据库多做大量无用聚合计算。尤其当分组键基数高（比如按user_id分上百万组），内存暴涨、查询超时、甚至OOM往往就在这一念之间。
典型反模式：
- 把
user_id IN (1001, 1002)这类可下推条件留在HAVING，而不是提前放进WHERE - 以为加个
GROUP BY 1就能让WHERE用上聚合函数——不行，WHERE的执行时机不会因加了GROUP BY就变晚
真正要盯住的，是数据量缩减的时机：WHERE筛行，HAVING筛组，差的不是写法，是那一层物理扫描和内存占用。
