MySQL 8.0+ 和 PostgreSQL 支持 HAVING 引用 SELECT 别名，但属扩展语法糖，标准 SQL 不保证；别名仅支持裸引用，不可参与运算或嵌套，跨库兼容应使用原始表达式。
MySQL 8.0+ 和 PostgreSQL 支持 HAVING 引用 SELECT 别名，但 SQL 标准不保证
SQL 标准规定：HAVING 子句在逻辑上执行于 GROUP BY 之后、但早于 SELECT 列计算完成——所以别名尚未存在。MySQL 8.0+ 和 PostgreSQL 做了扩展支持，允许你在 HAVING 里直接写 SELECT 中定义的别名，比如：
SELECT COUNT(*) AS cnt FROM orders GROUP BY user_id HAVING cnt > 5;
但这本质是语法糖，底层仍会把 cnt 替换回原始表达式 COUNT(*)。你不能依赖它做任意重命名，比如：
SELECT COUNT(*) * 1.0 AS cnt FROM orders GROUP BY user_id HAVING cnt > 5.0; -- ✅ 可行（MySQL 8.0+/PG）
SELECT COUNT(*) AS cnt FROM orders GROUP BY user_id HAVING cnt + 1 > 6; -- ❌ 大部分报错：别名不能参与运算
-
HAVING中别名仅支持“裸引用”，不支持加减乘除、函数调用、别名嵌套 - SQLite 和旧版 MySQL（no such column: cnt
- 即使支持，也建议优先用原始表达式，避免跨库迁移时意外失败
SQL Server 和 Oracle 完全不允许 HAVING 使用 SELECT 别名
它们严格遵循标准执行顺序：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。这意味着 HAVING 看不到 SELECT 里的任何别名，哪怕只是简单重命名。
常见错误现象：
Msg 207, Level 16, State 1, Line X: Invalid column name 'cnt'.
解决方式只有两种：
- 在
HAVING中重复写原始聚合表达式，例如HAVING COUNT(*) > 5 - 用子查询或 CTE 提前算出别名，再在外层过滤，例如：
WITH grouped AS (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) SELECT * FROM grouped WHERE cnt > 5;
注意：CTE 方式在 SQL Server/Oracle 中更安全，但多一层嵌套，小数据量无感，大数据量要注意执行计划是否退化
HAVING 里用别名 vs 用原始表达式，性能有差别吗？
没有。所有主流数据库都会在优化阶段把别名还原为原始表达式，最终执行的计划完全一致。你看到的 EXPLAIN 输出里，不会出现别名，只会有实际计算字段。
但容易踩的坑是：你以为写了别名就“只算一次”，其实不是。比如：
SELECT AVG(price) AS avg_p, MAX(price) AS max_p FROM products GROUP BY category HAVING avg_p > 100 AND max_p / avg_p > 2;
这段在 PostgreSQL 里能跑，但 avg_p 在 max_p / avg_p 中会被展开两次，相当于 MAX(price) / AVG(price)，而 AVG(price) 本身是窗口内计算，不会被缓存。这不是 bug，是设计使然。
- 别名不等于变量，不保存中间结果
- 想真正复用聚合结果，必须用子查询或 CTE
- 别为了“少打几个字”牺牲可移植性
跨数据库兼容写法：统一用原始表达式 + 注释说明意图
如果你的 SQL 要在 MySQL、PostgreSQL、SQL Server、Oracle 之间切换，最稳的方式就是放弃 HAVING 中的别名，老老实实写原表达式，并用注释交代业务含义：
SELECT COUNT(*) AS order_count, user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5; -- 过滤下单超5次的用户
这样既清晰，又不用记各库差异。工具链如 Flyway、Liquibase 或 ORM 的原生 SQL 模块，也更倾向这种写法。
真要抽象逻辑，交给应用层或视图，而不是靠方言特性硬撑。毕竟，HAVING 不是编程语言的 let 绑定，它只是过滤分组结果的一道闸门。
