差异出在哪
HAVING 能不能引用 SELECT 里定义的别名，是 MySQL 与 PostgreSQL 的明确差异：MySQL 允许在 HAVING、GROUP BY、ORDER BY 中直接写别名；PostgreSQL 的 HAVING 不支持别名，必须重复写聚合表达式，或把结果包成子查询。从 MySQL 迁到 PG 的报表 SQL 常在这里翻车。
基本信息
| MySQL | HAVING、GROUP BY、ORDER BY 都可以用别名 |
|---|---|
| PostgreSQL | HAVING 不可用别名；ORDER BY 可以用 |
| 迁移建议 | 优先重复写聚合表达式，跨库通用 |
| 替代方案 | 子查询包装后在 WHERE 里过滤 |
| 注意 | 重复写的表达式必须与 SELECT 里完全一致 |
典型使用场景
- 报表按分组过滤，例如只看计数超过阈值的分组
- 把 MySQL 的报表 SQL 迁移到 PostgreSQL
- 团队规范要求 SQL 跨库可移植
- 排查「MySQL 能跑、PG 报未知列」的差异
- 给重复出现的聚合表达式瘦身
MySQL 可以用别名
MySQL 可以用别名
-- MySQL：HAVING 直接引用 SELECT 里的别名 cnt
SELECT city, COUNT(*) AS cnt
FROM users
GROUP BY city
HAVING cnt > 5
ORDER BY cnt DESC; -- ORDER BY 同样支持别名PostgreSQL 的两种改写
PostgreSQL 的两种改写
-- 写法一：重复写聚合表达式，跨库通用
SELECT city, COUNT(*) AS cnt
FROM users
GROUP BY city
HAVING COUNT(*) > 5;
-- 写法二：子查询包装后在 WHERE 里过滤
SELECT * FROM (
SELECT city, COUNT(*) AS cnt
FROM users
GROUP BY city
) t
WHERE t.cnt > 5;各子句的别名与序号
| 子句 | MySQL | PostgreSQL |
|---|---|---|
| GROUP BY 别名 | 支持 | 支持（同名冲突时优先输入列） |
| HAVING 别名 | 支持 | 不支持，需写原表达式 |
| ORDER BY 别名 | 支持 | 支持 |
| WHERE 别名 | 不支持 | 不支持 |
| 按序号引用 | GROUP BY/ORDER BY 可写列序号 | GROUP BY/ORDER BY 同样可写序号 |
WHERE 与 HAVING 的求值位置不同：WHERE 在分组前过滤行，HAVING 在分组后过滤组。别名在 SELECT 里定义却在 HAVING 里引用，属于「后定义先使用」，只有 MySQL 放开这个限制。
重复写聚合表达式时务必与 SELECT 里保持一致：改一处漏一处会得到自相矛盾的结果——展示出来的计数和过滤条件对不上，这类问题在报表里非常难被发现。
迁移到 PostgreSQL 还有一条更省事的路径：把过滤条件挪到外层子查询，用 WHERE 过滤结果列，既躲开别名限制，也让过滤发生在聚合之后、排序之前，语义更清楚。
PostgreSQL 的 GROUP BY 虽然可以引用 SELECT 别名，但同名冲突时会优先解释成输入列，容易产生意外；跨库最稳的习惯是分组键与聚合表达式都按原样重复写。