WHERE中不能使用COUNT()或SUM()，因为SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，WHERE阶段聚合值尚未计算；必须用HAVING（配合GROUP BY）或子查询/窗口函数提前生成聚合列再过滤。
WHERE 里写 COUNT() 或 SUM() 不是数据库“不支持”，而是它根本还没算出来。
WHERE 执行时聚合值压根不存在
SQL 的真实执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着：WHERE 阶段看到的还是原始表的每一行，尚未分组，也未触发任何聚合计算。
- 你写
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 是唯一合法位置，但必须配 GROUP BY
HAVING 是专为聚合结果设计的过滤子句，但它不能单独存在：
- 没写
GROUP BY却用HAVING，MySQL 5.7+ 默认报错（语义模糊：对谁分组？），标准 SQL 不允许 -
HAVING COUNT(*) >= 3合法，因为此时每组的计数已算完；而HAVING cnt >= 3（引用SELECT中的别名）在 MySQL/PostgreSQL 中可行，但 SQLite 或旧版 MySQL 可能不认，建议优先复写表达式 - 性能上，
WHERE能大幅减少输入行数，HAVING只能筛组——像status = 'paid'这种条件必须放WHERE，硬塞进HAVING会让数据库先对百万行分组再扔掉 90% 的组
绕过 GROUP BY 的两种实操路径
如果业务只要“订单数 ≥ 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/SQL Server）：
SELECT user_id FROM (SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders) t WHERE cnt >= 3——窗口函数不能直出WHERE，必须先在派生表或SELECT中生成
真正容易被忽略的是：窗口函数和子查询都不是“让 WHERE 支持聚合”的捷径，而是把聚合值提前算好、变成普通列后再过滤。执行计划里多一层嵌套是常态，别指望它和原生 WHERE 一样轻量。
