WHERE中不能用COUNT()或SUM()，因SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，WHERE阶段聚合值尚未计算；应改用HAVING（需配合GROUP BY）或子查询、窗口函数、JOIN等替代方案。
WHERE子句里直接写 COUNT() 或 SUM() 会报错，不是语法写错了，而是数据库根本“还没算出这个值”。
WHERE 执行时聚合结果还不存在
SQL 的执行顺序是固定的：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着：WHERE 阶段只看到原始的每一行数据，所有行都还没分组，更没开始算 COUNT(*)、AVG(price) 这类值。你让它基于一个“不存在的结果”做判断，数据库只能拒绝。
常见错误现象：
-
WHERE COUNT(*) > 5：直接报语法错误（如 MySQL 的Invalid use of group function） -
WHERE SUM(amount) > 1000：同样报错，哪怕表里只有一行 - 旧版 MySQL（如 5.6）可能不报错但返回全表或空集——那是它偷偷把整张表当一组在算，行为不可靠，别依赖
HAVING 是 WHERE 的“分组后版本”
HAVING 必须跟在 GROUP BY 后面，它作用的对象是已经分好组、且各组聚合值已计算完成的结果集。这时用 COUNT(*)、AVG() 才有意义。
使用场景和要点：
- 必须有
GROUP BY，否则HAVING语义模糊（MySQL 5.7+ 默认报错） -
HAVING可以引用SELECT中定义的聚合别名，比如HAVING cnt > 3（而WHERE不行） - 性能上，
WHERE先筛行数，HAVING再筛分组数，所以能用WHERE过滤的条件（如status = 'paid'）别挪到HAVING里
示例：
SELECT user_id, COUNT(*) AS cnt FROM orders WHERE status = 'paid' -- ✅ 行级过滤，高效 GROUP BY user_id HAVING COUNT(*) >= 3; -- ✅ 分组后过滤，合法
没分组也要用聚合条件？绕开的三种方式
如果查询本身不需要分组（比如只想查“订单总数超过 100 的用户”），又想用聚合逻辑，HAVING 就不适用了。这时得换思路：
-
子查询：内层先聚合，外层用
WHERE比较结果，如WHERE order_count > 100（子查询返回单值） -
窗口函数（MySQL 8.0+ / PostgreSQL / SQL Server）：用
COUNT(*) OVER (PARTITION BY user_id)把聚合值“广播”到每行，再在外层WHERE里用——注意不能直接在WHERE里写窗口函数，要包一层派生表 -
JOIN 聚合结果：把聚合结果作为临时表
JOIN回原表，再过滤
最容易被忽略的一点：有些同学以为加个 GROUP BY 1 就能骗过语法检查，让 WHERE 用上聚合函数——不行。WHERE 的执行时机不会因为加了 GROUP BY 就变晚，它依然在分组前运行。
