WHERE不能直接用COUNT()等聚合函数，因为它在SQL执行顺序中早于GROUP BY和聚合计算，只能过滤原始行；HAVING才是用于过滤分组后结果的子句，需配合GROUP BY使用。
WHERE 为什么不能直接用 COUNT()、SUM() 等聚合函数
因为 WHERE 子句在 SQL 执行顺序中早于聚合计算，此时数据还没分组、也没算出聚合值，数据库根本“看不到” COUNT() 的结果。
MySQL（以及绝大多数 SQL 标准）的逻辑执行顺序大致是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。注意：WHERE 发生在 GROUP BY 和聚合函数求值之前，所以它只能过滤原始行，不能基于分组后的统计结果做判断。
HAVING 是 WHERE 的聚合版，但只能跟在 GROUP BY 后面
HAVING 才是专门用来过滤分组后结果的子句，它能安全使用 COUNT()、AVG()、MAX() 等聚合函数——前提是查询中已出现 GROUP BY。
- 没写
GROUP BY却用HAVING：MySQL 5.7+ 默认报错（除非开启ONLY_FULL_GROUP_BY关闭），因为语义不明确 -
HAVING可以引用SELECT中的别名（如HAVING cnt > 10），但WHERE不行 - 性能上，
WHERE先过滤行数，HAVING再过滤分组数，通常WHERE更高效
SELECT user_id, COUNT(*) AS cnt FROM orders WHERE status = 'paid' -- ✅ 过滤原始行 GROUP BY user_id HAVING COUNT(*) >= 3; -- ✅ 过滤分组结果
想在非分组查询里用聚合条件？得绕一下
如果确实需要“查出订单总数超过 100 的用户”，但又不想显式 GROUP BY，常见做法是用子查询或窗口函数（MySQL 8.0+）：
- 子查询方式：外层用
HAVING或直接比较，内层先聚合 - 窗口函数方式：用
COUNT() OVER (PARTITION BY user_id)生成每行的计数，再在WHERE里用 - 注意：窗口函数不能出现在
WHERE（仍受执行顺序限制），但可放在SELECT或HAVING，或用派生表包装后在外层WHERE
SELECT user_id FROM ( SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders ) t WHERE cnt >= 3;
容易踩的坑：WHERE + 聚合函数不报错但结果不对
某些旧版 MySQL（如 5.6）在没有 GROUP BY 时允许 WHERE COUNT() > 1，但这属于隐式单组聚合，行为不可靠：
- 实际会把整张表当作一个组，
COUNT(*)返回总行数，WHERE COUNT(*) > 1等价于“只要表有 2 行以上就返回所有行” - 结果集可能为空、全表、或只一行，完全取决于聚合值，和业务意图脱节
- 升级到 MySQL 8.0 或开启严格模式后，这类写法直接报错：
Invalid use of group function
真正要检查的是“哪些用户满足某聚合条件”，就必须明确分组边界——这是 SQL 模型本身的约束，不是 MySQL 特有的 bug 或缺陷。
