WHERE不能用COUNT、SUM等聚合函数，因其在分组前执行，只能访问原始行数据；正确做法是用GROUP BY后配合HAVING筛选分组结果。
WHERE 不能用 COUNT、SUM 这类聚合函数
因为 WHERE 在分组前执行，它看到的只是原始表里的一行一行数据，还没算过任何聚合值。你写 WHERE COUNT(*) > 10 或 WHERE AVG(salary) > 5000，数据库会直接报错——不是语法不支持，而是逻辑上根本没这东西可查。
常见错误现象：ERROR 1111 (HY000): Invalid use of group function
- 正确做法：想筛“订单数超 5 的客户”，必须先
GROUP BY customer_id，再用HAVING COUNT(*) > 5 - 反模式：把
status = 'paid'这种单行条件硬塞进 HAVING，既慢又绕 - 注意：WHERE 中可用的字段，必须是原表中存在的列，不能是 SELECT 里起的别名（比如
SELECT amount AS total WHERE total > 100会失败）
HAVING 必须紧跟 GROUP BY，且字段受限
HAVING 不是独立子句，它依赖分组结果存在。没有 GROUP BY，HAVING 就失去了筛选对象——除非数据库把整张表当成一个默认组（如某些 SQLite 版本），但语义模糊、不可靠，别这么写。
常见错误现象：Unknown column 'salary' in 'having clause'
- HAVING 只能引用两类字段：出现在
GROUP BY中的列，或 SELECT 中明确写出的聚合表达式（如COUNT(*)、AVG(salary)） - 不能引用原表中未分组也未聚合的字段，比如
HAVING salary > 8000（分组后已无单个 salary 值） - 别名可用：如果 SELECT 写了
AVG(salary) AS avg_sal，HAVING 就能用HAVING avg_sal > 5000；WHERE 则永远不能
WHERE 更快，该它干的活别推给 HAVING
WHERE 越早过滤掉无用行，后续分组和聚合要处理的数据就越少。把本该在 WHERE 做的过滤挪到 HAVING，等于让数据库白算一遍所有数据。
- 比如查“2025 年销售额超 10 万的地区”：用
WHERE year = 2025先缩小范围，再GROUP BY region求和，比全量分组后再HAVING SUM(sales) > 100000快得多 - 复合场景下，WHERE 和 HAVING 可共存：例如
WHERE status = 'active' GROUP BY dept HAVING COUNT(*) > 5，前者筛人，后者筛组 - 性能影响明显：千万级订单表中，WHERE 提前排除 90% 数据，聚合耗时可能从 3s 降到 0.3s
执行顺序决定一切，别凭直觉猜
SQL 实际执行链是固定的：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。这个顺序不是建议，是引擎强制走的流程。
容易被忽略的地方：HAVING 看到的是已经分好组、聚合完的结果集，它删掉的是“整个组”，不是某几行；而 WHERE 删掉的是原始行，这些行根本不会参与后续任何计算。
举个例子：SELECT dept, COUNT(*) FROM emp WHERE salary > 5000 GROUP BY dept HAVING COUNT(*) > 10 —— 先剔除所有工资 ≤5000 的员工，再按部门统计剩余人数，最后只保留人数超 10 的部门。中间那步“剔除”，直接影响最终 COUNT 的基数。
