HAVING执行早于SELECT，别名在SELECT阶段才定义，故标准SQL中HAVING无法使用SELECT别名；MySQL 8.0+/PostgreSQL仅支持裸引用语法糖，SQL Server/Oracle等严格拒绝。

HAVING 执行时机早于 SELECT 别名定义

别名在 SQL 逻辑执行顺序中只在 SELECT 阶段才被绑定到结果集，而 HAVING 发生在 SELECT 之前（完整顺序：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY）。这意味着当数据库解析 HAVING 时，COUNT(*) AS cnt 这个 cnt 根本还没“出生”，自然无法识别。

这不是数据库偷懒或实现缺陷，而是标准规定的执行语义。哪怕你写得再清楚，HAVING cnt > 100 在 SQL Server、Oracle、SQLite（默认）里都会报类似 Invalid column name 'cnt' 或 column "cnt" does not exist 的错误。

MySQL 8.0+ 和 PostgreSQL 的“裸引用”是语法糖，不是通用解法

MySQL 8.0+ 和 PostgreSQL 确实允许你在 HAVING 中直接写 cnt > 5，但这是它们各自做的扩展支持，底层会自动把 cnt 替换回原始表达式（如 COUNT(*)）。它只支持“裸引用”，不支持任何衍生用法：

• HAVING cnt > 5 ✅（仅限简单比较）
• HAVING cnt + 1 > 6 ❌（参与运算就崩）
• HAVING UPPER(cnt) ❌（函数调用不认）
• HAVING cnt IS NOT NULL ✅（部分版本支持，但非保证）

一旦你依赖这个特性写跨库 SQL，迁移到 SQL Server 或 Oracle 就立刻失效。更麻烦的是，团队里有人用 MySQL 开发，DBA 用 Oracle 做生产部署，这种写法就是隐形炸弹。

GROUP BY 不带子句时，HAVING 仍有效，但别名问题不变

即使没写 GROUP BY，HAVING 也能用——整张表会被当成一个组。例如检查 ID 是否连续：SELECT 'gap' FROM tbl HAVING COUNT(*) MAX(id) - MIN(id) + 1。但注意：这里没用别名，所以不触发问题。只要你试图在 HAVING 里引用 SELECT 中定义的别名（比如 AS total），规则照旧：标准不支持，多数库拒绝。

别名不可用和有没有 GROUP BY 无关，只和执行阶段有关。别名诞生于 SELECT，而 HAVING 永远等不到它。

可靠替代方案只有两个，别无捷径

想安全、可迁移、易维护，就只能选下面这两种：

• 在 HAVING 中重复原始表达式：HAVING COUNT(*) > 100 —— 最直白，零兼容风险，适合简单条件
• 用 CTE 或子查询提前固化别名：WITH g AS (SELECT dept, COUNT(*) AS cnt FROM emp GROUP BY dept) SELECT * FROM g WHERE cnt > 100 —— 语义清晰，支持任意后续计算（比如 cnt * 1.2 > 120），但要注意大数据量下执行计划是否退化（尤其外层 WHERE 是否能下推）

别指望优化器帮你“聪明地复用”别名——它不会。你写的每个别名，在 HAVING 里都等于不存在。真正容易被忽略的，是开发时图省事写的那行 HAVING cnt > 5，上线后在另一个环境里静默失败，连报错都可能被日志过滤掉。