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看到的还是原始行，每行都独立存在，COUNT(*)还没被“分组”这个动作触发，根本无从计算 - 你写
WHERE COUNT(*) > 5，数据库会直接抛出类似ERROR: aggregate function calls cannot contain column references（PostgreSQL）或Invalid use of group function（MySQL） - 哪怕表里只有一行，
WHERE COUNT(*) = 1也非法——不是值不对，是语法阶段就被拦下了
HAVING 是唯一能放聚合函数的地方
HAVING 必须跟 GROUP BY 一起出现，它作用的对象是“已经分好组、且各组聚合值已算完”的结果集：
- 正确写法：先
GROUP BY user_id，再用HAVING COUNT(*) >= 3 - 别名可用但不保险：MySQL 和 PostgreSQL 允许
HAVING total_cnt > 10（如果SELECT里写了COUNT(*) AS total_cnt），但 SQLite 或旧版 MySQL 可能不认，建议直接复写表达式 - 没写
GROUP BY却用了HAVING？MySQL 5.7+ 默认报错，因为语义模糊：对谁分组？整张表当一组？标准 SQL 不允许
想绕过 GROUP BY 又要聚合筛选？用子查询或窗口函数
如果你真不想显式分组（比如只想查“订单数 ≥ 3 的用户”，但结果只要 user_id 列），有两条路：
- 子查询：外层
WHERE比较的是内层聚合结果，例如WHERE user_id IN (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) >= 3) - 窗口函数（MySQL 8.0+ / PostgreSQL / SQL Server）：用
COUNT(*) OVER (PARTITION BY user_id)把聚合值“广播”到每行，再在外层WHERE过滤，例如：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 错放成 HAVING，不只是语法错，更是性能坑
把本该下推的条件留在 HAVING，会让数据库多做大量无用功：
-
WHERE status = 'paid'放对位置 → 扫描前就过滤掉无效订单，分组数据量小 - 错写成
HAVING status = 'paid'→ 先对全部订单（包括已取消的）分组，算完所有COUNT(*)，再扔掉 99% 的组 → 内存爆、查询慢、可能 OOM - 高基数分组（如按
user_id分上百万组）时，这个差异会立刻暴露
最常被忽略的一点：执行顺序不是理论，是硬约束。你不能靠“试试看”来判断某条聚合条件该放哪——先问自己：这个条件是筛原始行，还是筛分组结果？答案决定了它只能出现在 WHERE 或 HAVING 中的某一个位置，没有中间态。
