Azure Synapse专用SQL池GROUP BY无法识别重复数据问题

核心原因总结 #

这种现象几乎都是nvarchar字段存在肉眼不可见的内容差异，或是编码/长度导致的字符串实际值不同——直接GROUP BY会严格匹配二进制内容，而CAST转换会消除这些差异，从而识别出重复。

具体原因拆解 #

1. 不可见控制字符作祟 #

nvarchar字段里可能藏着空格、换行符、制表符，甚至Unicode零宽度空格（U+200B）这类肉眼看不到的字符。比如两个VBELN值看起来都是'SO12345'，但一个末尾多了个空格，直接GROUP BY时数据库会判定为不同字符串；而CAST转换（比如转成varchar）会自动处理这些冗余字符，让原本不同的字符串变成相同值，自然就能识别重复了。

2. Unicode与单字节编码的差异 #

nvarchar是UTF-16编码的Unicode类型，如果你CAST成varchar（单字节编码，比如默认的SQL_Latin1_General_CP1_CI_AS），一些特殊Unicode字符会被映射或截断。比如全角数字'１２３'和半角数字'123'，作为nvarchar是完全不同的，但转成varchar后会被统一为半角，就会被判定为重复行。

3. 字段长度截断导致的“伪重复” #

如果CAST时指定了比原nvarchar更短的长度，比如CAST(MANDT AS varchar(8))，而部分行的MANDT值长度超过8，被截断后就可能和其他行的截断值一致，原本不重复的行就被当成重复了。这种情况一般会有警告，但如果是意外的超长字符，也会出现这个问题。

4. MPP架构下的分组逻辑（概率较低） #

Synapse专用SQL池是MPP分布式架构，直接对nvarchar做GROUP BY时，各个节点的哈希分组逻辑可能和转换后不同，导致部分重复行没被聚合。但这种情况很少见，优先排查前三个原因。

验证排查方法 #

用以下SQL检查字段的二进制内容和实际长度，就能确认是否存在肉眼看不到的差异：

SELECT 
    MANDT, 
    VBELN, 
    posnr,
    -- 查看字符串的二进制原始值，对比是否有差异
    CONVERT(varbinary(MAX), MANDT) AS MANDT_bin,
    CONVERT(varbinary(MAX), VBELN) AS VBELN_bin,
    CONVERT(varbinary(MAX), posnr) AS posnr_bin,
    -- 查看字符串实际长度（包含不可见字符）
    LEN(MANDT) AS MANDT_len,
    LEN(VBELN) AS VBELN_len,
    LEN(posnr) AS posnr_len,
    COUNT(*) AS row_count
FROM your_table
GROUP BY MANDT, VBELN, posnr,
         CONVERT(varbinary(MAX), MANDT),
         CONVERT(varbinary(MAX), VBELN),
         CONVERT(varbinary(MAX), posnr),
         LEN(MANDT), LEN(VBELN), LEN(posnr)
HAVING COUNT(*) > 1;

如果这个查询能返回结果，说明确实是字符串二进制内容有差异。另外也可以试试用LTRIM(RTRIM(MANDT))替代CAST，看是否能识别重复，判断是不是空格导致的问题。

内容的提问来源于stack exchange，提问作者Aditya Rathi