如何在CASE语句中维持Binary(32)哈希值一致并处理NULL/0场景

问题根源 #

CASE表达式要求所有分支返回的数据类型必须统一，数据库会按照数据类型优先级自动做隐式转换。当你在CASE的一个分支返回全0的十六进制常量，另一个分支返回SHA2_256的二进制结果时，数据库可能会把哈希值先转换成字符串类型，再转回Binary(32)，这个转换过程直接导致了哈希值失真。

解决办法 #

核心思路是强制CASE的所有分支返回完全相同的数据类型，杜绝隐式转换的干扰。具体操作是给每个分支的结果显式指定为Binary(32)：

通用SQL写法示例 #

INSERT INTO your_target_table (hashkey_colA)
SELECT
    CASE
        WHEN source_col IS NULL OR source_col = 0 
            THEN CAST(0x0000000000000000000000000000000000000000000000000000000000000000 AS BINARY(32))
        ELSE CAST(SHA2(source_col, 256) AS BINARY(32))
    END
FROM your_source_table;

不同数据库的细节调整 #

• SQL Server：SHA2_256返回VARBINARY(32)，可以用CONVERT精准控制类型，同时注意数值类型源列要先转字符串再哈希：

  CASE
      WHEN source_col IS NULL OR source_col = 0 
          THEN CONVERT(BINARY(32), 0x0000000000000000000000000000000000000000000000000000000000000000)
      ELSE CONVERT(BINARY(32), HASHBYTES('SHA2_256', CAST(source_col AS VARCHAR(MAX))))
  END
  

• MySQL：SHA2默认返回十六进制字符串，需要用UNHEX转成二进制再指定类型：

  CASE
      WHEN source_col IS NULL OR source_col = 0 
          THEN CAST(UNHEX('0000000000000000000000000000000000000000000000000000000000000000') AS BINARY(32))
      ELSE CAST(UNHEX(SHA2(source_col, 256)) AS BINARY(32))
  END
  

验证方法 #

可以单独对比两种方式的结果，确认一致性：

1. 直接计算哈希：SELECT CAST(SHA2(source_col, 256) AS BINARY(32)) FROM your_source_table WHERE source_col IS NOT NULL AND source_col != 0;
2. 查看CASE分支结果：SELECT CASE ... END FROM your_source_table WHERE source_col IS NOT NULL AND source_col != 0;
   两者的十六进制输出应该完全一致。

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