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），外层就完全无法关联或过滤——别名再好也没用，数据链断了。
