SQL 避坑指南 - Oracle GROUP BY 整型常量的「薛定谔行为」

最近 PawSQL 的 SQL 解析器撞上了一个诡异的异常情况。

下面这条 SQL，在 Oracle 客户端里跑得好好的，PawSQL 却在解析时直接报了个数组越界：

SELECT category, count(1) 
FROM products 
GROUP BY category
UNION ALL
SELECT 3 as category, 100
FROM product_23
GROUP 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。

⚡ 这意味着同样的 SQL、同一个数据库版本、不同的参数设置，执行结果可能完全不同。

其他数据库的行为是什么？

这一点上，MySQL 和 PostgreSQL 走了另一条路——它们默认就把 GROUP BY 里的整数当作位置指示器。

也就是 GROUP BY 1 等价于按 SELECT 的第一列分组，和 Oracle（默认行为）截然相反。

跨数据库迁移时，这个差异是隐藏的定时炸弹。

💎 三条建议

1. 永远不要在 GROUP BY 里用常量。用明确的列名或别名，这是跨平台行为一致的唯一保证。
2. 如果非要用位置指示器（GROUP BY 1, 2），先确认目标数据库的版本和默认行为。
3. Oracle 23c 用户记得检查 GROUP_BY_POSITION_ENABLED——改了这个参数，所有用到位置分组的 SQL 行为都会变。

🔧 PawSQL 的应对措施

PawSQL在解决了这个SQL解析异常之后，还内置了一条审核规则——避免GROUP BY选择列的序号——专门在 SQL 进入生产环境之前，自动识别 GROUP BY 中使用整型字面量（无论是作为常量还是位置序号）的写法，并给出明确警告。整型常量可能导致分组行为在 Oracle/MySQL/PostgreSQL 之间完全不同；位置序号虽然多数数据库支持，却会显著降低代码的可读性和跨平台兼容性。