SQL中同一字节转换为INT与BIGINT结果差异的原因解析

这问题问到点子上了，核心原因在于二进制数据转整数时的字节截取规则、字节序和有符号整数的符号位，我给你一步步拆解：

1. 哈希结果的字节长度远大于目标整数类型 #

SHA2_512生成的是64字节的二进制数据，而SQL Server里：

• INT是4字节（32位）整数，范围是-2^31到2^31-1（即-2147483648到2147483647）
• BIGINT是8字节（64位）整数，范围是-2^63到2^63-1（即-9223372036854775808到9223372036854775807）

当你用CONVERT把二进制数据转成整数时，SQL Server只会取二进制数据的前N个字节（N是目标整数类型的字节数），后面的所有字节直接丢弃。也就是说：

• 转INT时，只取哈希结果的前4个字节来转换
• 转BIGINT时，取哈希结果的前8个字节来转换

这俩用的原始字节段都不一样，结果自然不可能相近。

2. 小端字节序的重组规则 #

SQL Server使用小端字节序（Little-Endian）来解析二进制到整数，简单说就是：二进制数组的第一个字节是整数的最低有效字节，最后一个字节是最高有效字节。

举个例子，假设你的哈希前4字节是0x12345678，转成INT时，实际会被解析成0x78563412（字节顺序反转），再转成十进制整数。

3. 有符号整数的符号位影响 #

INT和BIGINT都是有符号整数，它们的最高位（二进制的第31位/63位）是符号位：

• 如果最高位是1，转换后的整数就是负数
• 如果最高位是0，就是正数

这意味着即使截取的字节段里最高位是1，结果会直接变成负数，和另一种类型的结果差异会更明显。

验证你的示例 #

你可以用SUBSTRING明确截取对应字节段，验证转换逻辑：

SELECT 
    '00T1p000029eYmpEAE' AS OriginalString,
    -- 截取转INT用的前4字节
    SUBSTRING(HASHBYTES('SHA2_512', '00T1p000029eYmpEAE'), 1, 4) AS Int_SourceBytes,
    CONVERT(INT, SUBSTRING(HASHBYTES('SHA2_512', '00T1p000029eYmpEAE'), 1, 4)) AS IntValue,
    -- 截取转BIGINT用的前8字节
    SUBSTRING(HASHBYTES('SHA2_512', '00T1p000029eYmpEAE'), 1, 8) AS BigInt_SourceBytes,
    CONVERT(BIGINT, SUBSTRING(HASHBYTES('SHA2_512', '00T1p000029eYmpEAE'), 1, 8)) AS BigIntValue;

运行后你会发现，这个结果和你原来的查询完全一致，因为本质就是截取不同字节段再转换。

总结 #

导致结果巨大差异的三个核心点：

• 转换时截取的字节数量不同（4字节 vs 8字节）
• SQL Server采用小端字节序解析二进制到整数
• 有符号整数的符号位会直接影响结果的正负和数值大小

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