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，上线后在另一个环境里静默失败，连报错都可能被日志过滤掉。
