关于SQL里的聚合函数和WHERE条件之间的关系，其实是个挺经典的问题。先说几句大实话——WHERE子句跑得比聚合函数快，但它俩压根不在同一个阶段工作。
你猜怎么着？WHERE子句执行的时候，COUNT()、SUM()、MAX()这些值还根本没算出来。数据库连"每组有多少行"这个最基本的信息都不清楚，自然没办法用它来做过滤。就这么简单。
WHERE 阶段压根看不到聚合结果
SQL执行的真实顺序是：FROM → WHERE → GROUP BY → HA VING → SELECT。换句话说，WHERE只能看到原始表里一行行的数据，没有分组、没有统计数据、没有"组内总和"这种高阶概念。
- 如果你写了
WHERE COUNT(*) > 5，数据库会直接甩回来一句报错。PostgreSQL提示"aggregate functions are not allowed in WHERE"，MySQL则报"Invalid use of group function" - 哪怕表里只有一行数据，这句SQL也会被拦下——不是因为值不对，是在语法解析阶段就被拒绝了
- 也别想着用别名绕过去：先写
SELECT COUNT(*) AS cnt，再写WHERE cnt > 5，照样不合法。WHERE压根看不到SELECT阶段定义的别名
HA VING 是唯一合法位置，但必须配 GROUP BY
HA VING跑在GROUP BY之后，这个时候每组的COUNT(*)、A VG(price)都已经算好了，可以直接用。
- 如果没写GROUP BY却用HA VING，MySQL 5.7以上版本默认会报错（语义不明确）
HA VING COUNT(*) >= 3没问题；HA VING cnt >= 3在MySQL和PostgreSQL中也可以用，但如果要考虑兼容SQLite或较老版本，还是老老实实写完整表达式更稳妥- 一个容易被忽略的优化点：能下推到WHERE的条件千万别塞进HA VING。比如
status = 'paid'这种行级过滤条件，放在WHERE里能大幅减少分组的数据量；硬塞HA VING的话，等于让数据库傻乎乎地算完上百万组再扔掉，属于搬起石头砸自己的脚
没分组也想用聚合逻辑？得换写法
有的业务场景比较特殊，比如你想查"订单数大于等于3的用户"，但不想在最终结果里显式出现GROUP BY。那就要绕开执行顺序的限制：
- 子查询：内层先做聚合，外层用WHERE来比较结果。例如
SELECT user_id FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t WHERE t.cnt >= 3。这是最常见、最直观的解法 - 窗口函数（MySQL 8.0+/PostgreSQL支持）：用
COUNT(*) OVER (PARTITION BY user_id)给每行附上该用户的订单数，然后在外层WHERE中引用。注意窗口函数本身不能在WHERE里直接使用，必须先出现在SELECT或派生表中 - 标量子查询也行：
WHERE (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) >= 3，但性能通常比较差，数据量大时容易变成N+1查询，最好谨慎使用
最后想强调一个常被忽视的点：把条件错放在HA VING里，不只是语法问题，它会让数据库多做大量无用的聚合计算。尤其是当分组键基数很高（比如按user_id分出上百万组）时，内存暴涨、查询超时、甚至OOM的风险，往往就源于这个看似不起眼的选择。
