最近 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 之间完全不同；位置序号虽然多数数据库支持，却会显著降低代码的可读性和跨平台兼容性。