GROUP BY 和 HA VING 得联手才能发挥过滤分组结果的作用；单独甩一个 HA VING 出来，数据库直接报错——因为连分组都没做，哪来的“分组后”数据可以筛？另外，SELECT 里那些非聚合字段，必须老老实实出现在 GROUP BY 子句里，否则会触发 ERROR 1055；HA VING 呢，只能引用聚合函数或者分组字段，原始行里的单值字段就别想了。
说白了，GROUP BY 和 HA VING 是“捆绑销售”——单独写 HA VING 就是找死，因为没有分组就没有“分组后”的数据可筛。
GROUP BY 后 SELECT 字段必须合法
MySQL（以及大多数标准 SQL）有个硬规矩：SELECT 列表里出现的每个非聚合字段，都得出现在 GROUP BY 子句中。否则，严格模式下直接给你甩个 ERROR 1055，毫不留情。
- ✅ 正确写法：
SELECT department, COUNT(*) FROM employees GROUP BY department;—— 所有非聚合字段都在 GROUP BY 里，没问题。 - ❌ 错误示范：
SELECT name, department, COUNT(*) FROM employees GROUP BY department;——name既没在 GROUP BY 里，也没套上聚合函数，数据库一脸懵：到底取哪一行的 name？ - ⚠️ 提醒一下：MySQL 5.7+ 默认启用了
ONLY_FULL_GROUP_BY模式，这个限制是写死的。有人想关掉它逃避错误，但关掉只是掩盖问题，不是解决问题，该按规矩来还是得按规矩来。
HA VING 只能用聚合结果或分组字段做条件
HA VING 是对“每组聚合完之后”那行结果做判断，所以条件里放心用 COUNT(*)、SUM(amount) 这些聚合函数就行，但不能打原始行单值字段的主意（除非那个字段也在 GROUP BY 里）。
- ✅ 正确用法：
HA VING COUNT(*) > 3、HA VING A VG(salary) >= 12000、HA VING department = 'tech'（因为 department 是分组字段，没问题） - ❌ 错误用法：
HA VING salary > 10000—— salary 不是分组字段，也不是聚合结果，这一行根本就不存在于 HA VING 执行时的上下文里，数据库会直接报错。 - ? 小技巧：如果想先筛出高薪员工再分组，应该用
WHERE salary > 10000放在 GROUP BY 前面，而不是硬塞进 HA VING 里。WHERE 是分组前干的活，HA VING 是分组后干的活，分工明确。
WHERE 和 HA VING 的执行顺序不能颠倒
SQL 实际执行顺序是这样的：FROM → WHERE → GROUP BY → 聚合计算 → HA VING → SELECT → ORDER BY。这个顺序决定了什么能做什么不能做，搞反了就出岔子。
- WHERE 在分组前运行，所以效率更高——能提前砍掉大量不需要的数据，减少参与分组的行数，对大表来说至关重要。
- HA VING 在分组后运行，是对已经算好的组进行筛选，无法绕过聚合计算。比如
HA VING COUNT(*) > 100，数据库必须先把所有组的计数全算出来，再一个一个比较。 - ? 场景对比：查“订单总额超过 5000 且下单次数 ≥ 3 的客户”。
→ 先WHERE order_date >= '2025-01-01'缩小范围；
→ 再GROUP BY customer_id；
→ 最后HA VING SUM(amount) > 5000 AND COUNT(*) >= 3。
容易被忽略的一点是：HA VING 条件里写的别名（比如 AS total），在某些数据库（如 PostgreSQL）里可以直接用，但在 MySQL 8.0 之前不支持——得老老实实重复写 SUM(amount) > 5000，不能写 total > 5000。别名能不能用，取决于具体版本和 SQL 模式，千万别默认它一定行，提前查一下文档更稳妥。
