HAVING只能筛选分组后的聚合结果或GROUP BY字段，不能使用SELECT别名或外层计算列；对聚合结果的二次加工（如高于平均值）必须用子查询或CTE，且子查询必须带别名，关键分组字段不可遗漏。

别名本身不能直接用于 HAVING 或 WHERE 做二次筛选——这是绝大多数人踩坑的起点。真正能筛分组结果的只有 HAVING，而想对聚合结果再加工（比如“订单数高于平均值的用户”），必须用子查询或 CTE，且内层结果必须带别名。

子查询必须加别名，否则报错 Every derived table must have its own alias

MySQL 和 PostgreSQL 都强制要求：FROM 后的子查询必须有别名，哪怕只用一次。这不是可选项，是解析器硬性规则。

• 错： SELECT * FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) → 直接报错
• 对： SELECT * FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) AS t
• 别名不能含空格或横线：user_summary 可以，user-summary 或 user summary 会语法错误
• 如果外层还要 JOIN 这个子查询，别名最好语义清晰，避免和真实表名冲突（比如别叫 orders）

HAVING 只能筛分组后字段，不能引用别名或外层计算列

HAVING 的作用域仅限于 GROUP BY 输出列和聚合函数本身。它看不见 SELECT 中定义的别名，也看不到外层计算逻辑。

• 错：SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id HAVING cnt > 10 → 表面看没问题，但若 cnt 是别名而非原始聚合表达式，某些严格模式（如 PostgreSQL）会拒绝
• 更稳妥写法：HAVING COUNT(*) > 10，不依赖别名
• 错：HAVING AVG(amount) > (SELECT AVG(amount) FROM orders) → 子查询不能在 HAVING 里嵌套（MySQL 允许但语义模糊，PostgreSQL 不支持）
• 想筛“高于均值的分组”，必须把均值算出来放外层，比如用 CTE 或子查询先算均值再 JOIN 或 WHERE 比较

CTE 更适合多次复用分组结果做不同方向的二次加工

当你需要对同一份分组结果做多个操作（比如既取 Top 3，又算平均值，再筛出超均值的记录），CTE 比重复写子查询更安全、更易维护。

• CTE 定义后必须紧跟主查询，中间不能插 INSERT 或 UPDATE
• 示例：WITH user_orders AS (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) SELECT user_id FROM user_orders WHERE cnt > (SELECT AVG(cnt) FROM user_orders)
• MySQL 8.0+ 和 PostgreSQL 都支持，但 MySQL 5.7 不支持 CTE，得退回到带别名的子查询
• CTE 内部不能引用自身（除非显式声明 RECURSIVE），普通汇总场景不用递归

最常被忽略的一点：子查询或 CTE 里漏掉关键分组字段（比如只 SELECT COUNT(*) 却没选 user_id），外层就完全无法关联或过滤——别名再好也没用，数据链断了。