Sql 负号在计算的校验和值中表示什么？

我正在使用MS SQL中的CHECKSUM（）函数计算哈希值。为什么有些计算值有正号，有些有负号

SELECT CommodityName, CHECKSUM(CommodityName) FROM Table1

结果:

CommodityName        Checksum
BuildingSupplies    -1674787472
Cutting Tools        1343439447
Electrical           1703618888
Filtration          -1653028371
PPE                 -2086698034
Spare Parts          1752220254
Welding             -178487827

评论的时间太长了——尽管这不是问题的直接答案。自从你声明你正在计算散列值后，我就开始发帖了

，因为您可能会将此值与散列后的另一个值进行比较

具体地说。。。从

校验和满足哈希函数的属性：应用校验和 如果 两个列表的对应元素具有相同的类型，并且 使用等于（=）运算符进行比较时等于。为此 定义中，指定类型的空值被视为比较 平等。如果表达式列表中的某个值发生更改，则 列表的校验和通常也会更改。然而，有一个小的 校验和不会更改的可能性。

---

因此，您可能想改用

这是对这个老问题的间接回答，但如果有人来到这里寻找一种方法来获取始终为正数（例如，保存十六进制表示法），请尝试将2147483648添加到结果中，得到0到4294967295之间的值

有必要铸造到bigint：

DECLARE @k bigint = CAST(CHECKSUM(…) As bigint) + 2147483648;

---

因为

校验和（）。它是特定于论点的吗？我不明白-你说的特定于论点是什么意思
CHECKSUM（）
计算基于
INT
的值哈希。
INT
可以是
-2147483648
到
2147483647
的任意位置。因此，大约有一半的时间，它将是负的。我不确定这个问题。校验和的输出没有任何“意义”。这只是一个不透明的标记。有些是偶数，有些是奇数，这也不意味着什么。@Madhukar它们不是“随机”给出的。它们有负号的唯一条件是。。。好。。。作为一个负数…为什么不直接使用
ABS（）
来确保始终是正数？@hoppeduppen但如果使用
CHECKSUM（）
作为哈希函数，则应尽量避免冲突。由于使用
ABS（）
会从结果中删除符号位，因此使用int 31而不是int32。此操作将产生50%冲突可能性的哈希数从（大约）77000减少到55000。因此，通过一个简单的加法，您可以保持32位为您工作。您可以看到删除一位如何使概率函数比另一位（32b蓝色）更陡峭（31b红色）。