GROUP BY不能使用SELECT中的别名，因SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，别名在SELECT阶段才生成，而GROUP BY在其之前执行，故引用会报错。
GROUP BY 不能直接用别名分组
很多人写完 COUNT(*) AS num_prods，就想在 GROUP BY 里写 GROUP BY num_prods——这会报错。SQL 标准规定：GROUP BY 子句中出现的列，必须是 SELECT 列表中的原始列名或表达式，**不能是别名**，也不能是聚集函数本身。
常见错误现象：Invalid column name 'num_prods'（SQL Server）或 Unknown column 'num_prods' in 'group statement'（MySQL）。
- 正确做法：如果要按计算逻辑分组，得把整个表达式原样写进
GROUP BY，比如GROUP BY SUBSTRING(product_name, 1, 3) - 若表达式复杂（如嵌套函数），建议先用子查询或 CTE 提前算好，再对外层结果分组
- 注意：不同数据库对表达式重复性的容忍度不同，PostgreSQL 要求严格一致，MySQL 8.0+ 允许部分简化，但不推荐依赖
计算字段本身不能作为 GROUP BY 的唯一依据
想“按产品数量分组”，比如查“哪些供应商恰好提供 4 个产品”，不能写 SELECT vend_id, COUNT(*) FROM Products GROUP BY COUNT(*)——语法非法。因为 GROUP BY 必须基于非聚合列来切分数据，而 COUNT(*) 是聚合结果，还没产生。
正确路径是两步：先分组统计，再用 HAVING 筛选结果。
- 错误写法：
GROUP BY COUNT(*)→ 直接报错 - 正确写法：
GROUP BY vend_id HAVING COUNT(*) = 4 - 若需进一步按数量区间归类（如“1–3个”“4–6个”），得用
CASE WHEN COUNT(*) ... END包裹后，在外层查询中分组，或用子查询
多字段分组时，计算字段参与逻辑要显式写出
比如要统计“每个供应商中，价格高于平均价的产品数量”，不能只写 GROUP BY vend_id 就完事。因为“高于平均价”这个判断依赖全表或分组内均值，必须明确作用域。
典型场景是：先算出各供应商均价，再和单条记录比对。这时计算字段（如 price > AVG(price) OVER (PARTITION BY vend_id)）属于窗口表达式，不能放进 GROUP BY；但你可以用它生成布尔列，再在外层 GROUP BY vend_id, is_above_avg。
- 关键限制：所有出现在
SELECT非聚合位置的列，只要没被聚合函数包裹，就必须出现在GROUP BY中 - 如果用了窗口函数生成新列，它本质是每行一个值，可以参与分组，但要注意逻辑是否符合业务预期（比如一行一个布尔值，分组后就只剩两个组）
- 避免在
GROUP BY里混用窗口函数和普通列，容易触发“non-deterministic grouping”警告（尤其在 MySQL 5.7）
WHERE 和 HAVING 混用时，计算字段的位置决定过滤时机
计算字段能否用于 WHERE，取决于它是否依赖聚合。例如 price * 1.1 > 100 可以放 WHERE（每行独立计算），但 COUNT(*) > 2 必须放 HAVING（分组后才有意义）。
最容易忽略的一点：HAVING 过滤的是分组后的结果集，它看到的“计算字段”只能是聚合函数输出，或者 GROUP BY 中声明的原始字段。你无法在 HAVING 里引用一个未出现在 SELECT 或 GROUP BY 中的表达式。
- 合法：
HAVING AVG(price) > 500 - 非法：
HAVING price > 500（除非price在GROUP BY中） - 更隐蔽的坑：
SELECT vend_id, COUNT(*) AS cnt FROM Products GROUP BY vend_id HAVING cnt > 3——虽然cnt是别名，但多数数据库允许在HAVING中使用它，这是少数例外；但不要在GROUP BY或WHERE中效仿
实际执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT，这意味着你在 HAVING 里能“看到”的，只是刚分完组、尚未投影出别名的中间结果。任何想绕过这个顺序去提前引用聚合结果的操作，都会失败。
