下面这条 SQL，在 Oracle 客户端里跑得好好的，PawSQL 却在解析时直接报了个数组越界：
SELECT category, count(1)FROM productsGROUP BY categoryUNION ALLSELECT 3 as category, 100FROM product_23GROUP BY 3
PawSQL解析器试图把 GROUP BY 3
映射到 SELECT 列表的第 3 列——但 SELECT 列表总共才 2 列。 数组越界了！
修复数组越界很简单，但是想要完善的解决这个问题需要搞清楚一个更深层的问题：GROUP BY
里的整型常量，到底是「列位置」还是「纯数值」？
而答案取决于你在用哪个数据库——以及 Oracle 的哪个版本。
Oracle 23c 之前：整型常量就是常量
在 Oracle 23c 之前，GROUP BY 3
里的 3
就是一个普通常量值。
📊 实际效果：所有行被分到同一组。因为 3
是个常量，GROUP BY 常量等价于不分组。
这在大多数场景下不是用户的本意——你很可能想表达的是「按第 3 个选择列分组」。
Oracle 23c 之后：新增了一个开关
Oracle 23c 引入了一个关键参数：GROUP_BY_POSITION_ENABLED
。
FALSE | GROUP BY 3→ 按常量分组（默认行为） |
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 之间完全不同；位置序号虽然多数数据库支持，却会显著降低代码的可读性和跨平台兼容性。
