可以用，但前提是数据库本身支持这一写法。像MySQL、PostgreSQL、SQL Server这类数据库，支持使用GROUP BY 1，也就是按照SELECT列表里的第1个字段分组；Oracle则不支持。问题在于，这种写法虽然省事，却很容易带来维护风险：语义不够直观，逻辑也比较隐蔽，一旦后续重构或调整SELECT字段顺序，出错的概率会明显上升。所以，生产环境里并不建议这么写，优先使用明确的列名或别名，通常更稳妥。

GROUP BY 能不能用 SELECT 字段序号（比如 GROUP BY 1）？

能，但仅限部分数据库，且强烈不建议在生产 SQL 中使用。

MySQL、PostgreSQL、SQL Server 都支持 GROUP BY 1 这种写法——它表示“按 SELECT 列表中第 1 个字段分组”。但这只是语法糖，背后不改变语义，反而容易埋坑。

• MySQL：默认允许 GROUP BY 1，但前提是该序号对应的是一个确定的、非表达式的列（比如 SELECT a, b + c FROM t 中 GROUP BY 2 会报错，因为 b + c 不是原始列）
• PostgreSQL：支持，但要求序号指向的必须是简单列名或别名，不能是复杂表达式
• SQL Server：支持，但只认 SELECT 列表中“裸列名”或“明确别名”，比如 SELECT name AS n FROM t GROUP BY 1 可行，SELECT UPPER(name) GROUP BY 1 会失败
• Oracle：不支持字段序号，直接报错 ORA-00979: not a GROUP BY expression

为什么 GROUP BY 1 容易出错？

问题不在语法能否通过，而在于可维护性和歧义风险。

• 当 SELECT 列表被重构（比如加了新字段、调换顺序），GROUP BY 1 指向的字段就悄悄变了，查询逻辑可能完全偏离预期，但数据库不报错
• 嵌套查询或视图中，外层 GROUP BY 1 实际引用的是内层 SELECT 的第 1 列，层级一多根本没法快速判断分组依据
• 和 HA VING 或 ORDER BY 混用时，三者都用序号容易互相干扰，比如 ORDER BY 1 和 GROUP BY 1 指的未必是同一列
• 团队协作时，没人愿意花时间数“第几个字段”，尤其 SELECT 有 8 个字段+别名时

替代方案：怎么写更安全？

用字段名或别名，而不是数字序号。哪怕多打几个字，也比后期 debug 半天强。

• 优先用原始列名：GROUP BY department，而不是 GROUP BY 1（即使 SELECT department, ...）
• 如果用了别名，就用别名：SELECT dept_name AS department, COUNT(*) FROM t GROUP BY department 是合法且清晰的
• 多字段分组时，别省略——GROUP BY department, hire_year 比 GROUP BY 1, 2 明确十倍
• 在 MySQL 中，如果启用了 ONLY_FULL_GROUP_BY（默认开启），GROUP BY 1 仍需确保该序号列是确定性、非聚合的，否则照样报错

真正麻烦的不是写 GROUP BY department 多敲三个字母，而是某天凌晨三点发现报表数据对不上，追查两小时才发现有人把 SELECT 顺序改了，而 GROUP BY 2 还静静躺在那儿。

《夸克》非常好用的免费AI浏览器

下载APP查看