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 或缺陷。
