where不能使用聚合函数，因sql执行顺序为from→where→group by→having→select，where阶段尚未分组、聚合值根本不存在；正确做法是用having（需配合group by）、子查询或窗口函数替代。
WHERE阶段聚合值根本不存在
你写 WHERE COUNT(*) > 5，数据库不是“算出来再比较”，而是直接在语法解析阶段就拒绝——PostgreSQL 报 aggregate functions are not allowed in WHERE，MySQL 8.0+ 报 Invalid use of group function。这不是语法写错了，是执行顺序决定了此时压根没生成任何聚合值。
SQL 的真实执行顺序固定为：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着 WHERE 看到的只是原始表的一行行数据，连“按 user_id 分组”都还没发生，更别说每组有多少条记录了。
- 哪怕表只有一行，
WHERE COUNT(*) = 1依然非法——问题不在数值对不对，而在于这个值此刻根本没生成 - 旧版 MySQL（如 5.6）可能不报错，但会把整张表当一个隐式组来算，导致
WHERE COUNT(*) > 1实际等价于“只要总行数 ≥ 2 就返回全表”，逻辑完全失控 -
WHERE看不到SELECT中定义的别名，比如SELECT COUNT(*) AS cnt后写WHERE cnt > 5，照样报错
HAVING才是聚合后过滤的唯一合法位置
HAVING 是专为聚合结果设计的子句，它运行在 GROUP BY 完成、各组聚合值已计算完毕之后。这时用 COUNT(*) 或 AVG(price) 才有意义。
- 必须和
GROUP BY成对出现；没写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% 的组，极易 OOM 或超时
子查询方式绕开执行顺序限制
如果业务只要“订单数 ≥ 3 的用户 ID”，又不想最终结果里带 COUNT(*) 列，就不能硬套 GROUP BY + HAVING，得用子查询把聚合结果当临时表来用。
- 内层必须有别名，否则 MySQL 8.0+/PostgreSQL 会报错：
SELECT user_id FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t WHERE t.cnt >= 3 - 子查询中若涉及空值（如
region IS NULL），直接JOIN会丢记录；稳妥做法是先在子查询里加WHERE region IS NOT NULL - 用
EXISTS更适合“查满足聚合条件的原始行”场景，例如查所有至少发过 3 条评论的用户的全部评论：SELECT * FROM comments t1 WHERE EXISTS (SELECT 1 FROM comments t2 WHERE t2.user_id = t1.user_id GROUP BY t2.user_id HAVING COUNT(*) >= 3)
窗口函数方式替代（MySQL 8.0+/PostgreSQL）
窗口函数能把聚合值“广播”到每行，不改变原始行数，适合既要明细又要分组统计的场景。
- 窗口函数本身不能直出
WHERE，必须先在SELECT或派生表中生成，再在外层WHERE引用：SELECT user_id FROM (SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders) t WHERE cnt >= 3 -
PARTITION BY语义等价于GROUP BY的分组逻辑，但不折叠行；空值默认被归为同一组，如需排除，加WHERE user_id IS NOT NULL - 相比子查询，窗口函数通常性能更稳，尤其在需要多维度聚合（如同时算区域总额 + 每行占比）时，避免重复聚合和 JOIN 空值陷阱
最常被忽略的一点是：错把条件放 HAVING 不只是语法问题，它会让数据库多做大量无用聚合计算——尤其当分组键基数高（比如千万级 user_id）时，内存暴涨、查询超时、甚至 OOM 都非常真实。
