having不能直接过滤未分组的原始列，因其作用对象是分组后的聚合结果而非原始行；若name未出现在group by中或未被聚合函数包裹，数据库会报错，必须用where提前筛选或通过max(case...)等聚合方式转换逻辑。
HAVING 不能直接过滤未分组的原始列
HAVING 的作用对象是分组后的聚合结果，不是原始行。如果你写 HAVING name = 'Alice'（而 name 没出现在 GROUP BY 中，也没被聚合函数包裹），绝大多数数据库（如 MySQL 5.7+ 严格模式、PostgreSQL、SQL Server）会直接报错，比如：column "name" must appear in the GROUP BY clause or be used in an aggregate function。
根本原因：分组后，“每组一行”，原始列值可能有多个，数据库无法确定你指哪一条 —— 它不帮你猜，也不允许歧义。
想按原始列值筛选分组，得先用 WHERE
如果目标是“只对满足某原始列条件的行做分组”，必须把条件移到 WHERE 子句。例如：统计每个部门里工资 > 5000 的员工人数：
SELECT dept, COUNT(*) FROM employees WHERE salary > 5000 GROUP BY dept;
WHERE 在分组前过滤行，HAVING 在分组后过滤组 —— 这个顺序不能颠倒。
-
WHERE可用任何原始列、表达式、甚至子查询（只要支持） -
WHERE过滤后才分组，性能通常更好（减少分组数据量） - 别试图用
HAVING替代WHERE，除非你真需要基于聚合结果筛选（比如HAVING COUNT(*) > 5）
非要基于原始列值做分组后筛选？用聚合函数包装它
极少数场景下，你确实需要“分组后，检查该组是否包含某个原始值”，比如：“找出所有至少有一名 manager 的部门”。这时不能写 HAVING role = 'manager'，但可以写：
SELECT dept FROM employees GROUP BY dept HAVING MAX(CASE WHEN role = 'manager' THEN 1 ELSE 0 END) = 1;
本质是把原始列逻辑转为聚合判断：
-
MAX(CASE ...)或BOOL_OR(role = 'manager')（PostgreSQL）等价于“该组是否存在” -
MIN()/MAX()配合CASE是跨数据库最稳妥的方式 - 注意：
ANY_VALUE(name)（MySQL）或FIRST_VALUE(name)（窗口函数）能取值，但不等于“过滤”——它们不改变分组数量，只是选一个代表值
MySQL 5.7 之前的宽松模式是个陷阱
旧版 MySQL 允许 HAVING 引用非分组、非聚合列（如 HAVING name = 'Alice'），但它实际行为是：从每组中**随机取一个** name 值来判断。结果不可靠，且升级到 5.7+ 或开启 ONLY_FULL_GROUP_BY 后立刻报错。
所以：
- 别依赖这种行为，哪怕当前没报错
- 检查你的 SQL mode：
SELECT @@sql_mode;，确认含ONLY_FULL_GROUP_BY - 开发时就按标准 SQL 写，避免上线后突然崩
真正难的不是语法，而是想清楚——你要筛的是“行”，还是“组”。选错位置，HAVING 就永远帮不上忙。
