Oracle 19c中PARTITION BY会话级大小写不敏感异常排查求助

首先明确Oracle 19c中NLS参数对分组逻辑的核心影响：

• 当NLS_COMP=BINARY时，所有涉及相等性判断的操作（包括GROUP BY、PARTITION BY）都会基于字符的二进制编码进行比较，严格区分大小写。此时NLS_SORT=BINARY_CI仅影响排序顺序，不会改变相等性判断规则。
• 若要实现PARTITION BY不区分大小写、GROUP BY保持敏感的需求，唯一原生可行的方式是在PARTITION BY子句中显式指定大小写不敏感规则，例如：

  PARTITION BY NLSSORT(your_column, 'NLS_SORT=BINARY_CI')
  

  同时GROUP BY直接使用原列。

针对你遇到的客户端差异问题，核心原因在于SQL Developer的会话初始化或查询处理逻辑与SQLPlus、Toad存在差异：

• 你的SQLPlus和Toad会话中，查询语句本身应该包含了PARTITION BY的显式大小写不敏感处理（比如上述的NLSSORT调用），因此结果符合预期。
• 而SQL Developer中出现异常的可能情况有两种：
  1. 会话参数被隐式修改：SQL Developer默认会根据本地操作系统区域设置，在连接后自动执行ALTER SESSION语句调整NLS参数。即使你查看的会话参数显示NLS_COMP=BINARY，也可能存在查询执行前参数被临时修改的情况，导致PARTITION BY使用了大小写不敏感的比较规则。
  2. 查询语句被隐式转换：部分版本或配置的SQL Developer会对查询语句进行自动转换，比如将PARTITION BY your_column自动替换为PARTITION BY UPPER(your_column)，实现了大小写不敏感的分区，但GROUP BY仍保留原列的二进制比较逻辑，最终出现你看到的结果。

验证建议：

• 在SQL Developer中执行查询前，先执行ALTER SESSION SET NLS_COMP=BINARY; NLS_SORT=BINARY;强制重置参数，再执行原查询观察结果变化。
• 通过Oracle的V$SQL视图对比SQL Developer和SQLPlus中执行的实际SQL文本，确认是否存在隐式转换。

内容的提问来源于stack exchange，提问作者David Lomax