最近 PawSQL 的 SQL 解析器撞上了一个诡异的异常情况。
下面这条 SQL，在 Oracle 客户端里跑得好好的，PawSQL 却在解析时直接报了个数组越界：
SELECT category, count(1) FROM products GROUP BY CATEGORY UNION ALL SELECT 23 as category, 100 FROM product_23 GROUP BY 23解析器试图把GROUP BY 23映射到 SELECT 列表的第 23 列——但 SELECT 列表总共才 2 列。越界了。
这引出一个更深层的问题：GROUP BY里的整型常量，到底是「列位置」还是「纯数值」？
答案取决于你在用哪个数据库——以及 Oracle 的哪个版本。
Oracle 23c 之前：整型常量就是常量
在 Oracle 23c 之前，GROUP BY 23里的23就是一个普通常量值。
📊实际效果：所有行被分到同一组。因为23是个常量，GROUP BY 常量等价于不分组。
这在大多数场景下不是用户的本意——你很可能想表达的是「按第 23 个选择列分组」。
Oracle 23c 之后：新增了一个开关
Oracle 23c 引入了一个关键参数：GROUP_BY_POSITION_ENABLED。
| 参数值 | 行为 |
|---|---|
FALSE（默认） | 保持旧行为，GROUP BY 23→ 按常量分组 |
TRUE | GROUP BY中的正整数视为位置指示器，指代 SELECT 列表的第 N 列 |
⚡ 这意味着同样的 SQL、同一个数据库版本、不同的参数设置，执行结果可能完全不同。
其他数据库怎么做？
这一点上，MySQL 和 PostgreSQL 走了另一条路——它们默认就把 GROUP BY 里的整数当作位置指示器。
也就是GROUP BY 1等价于按 SELECT 的第一列分组，和 Oracle（默认行为）截然相反。
跨数据库迁移时，这个差异是隐藏的定时炸弹。
💎 三条建议
- 永远不要在 GROUP BY 里用常量。用明确的列名或别名，这是跨平台行为一致的唯一保证。
- 如果非要用位置指示器（
GROUP BY 1, 2），先确认目标数据库的版本和默认行为。 - Oracle 23c 用户记得检查
GROUP_BY_POSITION_ENABLED——改了这个参数，所有用到位置分组的 SQL 行为都会变。
🔧 PawSQL 的应对措施
PawSQL在解决了这个SQL解析异常之后，还内置了一条审核规则——避免GROUP BY选择列的序号——专门在 SQL 进入生产环境之前，自动识别GROUP BY中使用整型字面量（无论是作为常量还是位置序号）的写法，并给出明确警告。整型常量可能导致分组行为在 Oracle/ MySQL/ PostgreSQL 之间完全不同；位置序号虽然多数数据库支持，却会显著降低代码的可读性和跨平台兼容性。
