我正在使用 Murmurhash3 为文本条目创建唯一的哈希值。创建文本条目时，我使用的是 this php implementation ，它返回一个 32 位哈希整数，以获取哈希值。散列存储在 BINARY(16) 数据库列中。我还需要更新我们现有的数据库，所以我正在使用 this MySql implementation更新数据库。为了匹配 php 创建的散列，我将其转换为基础并将其小写。
UPDATE column SET hash=LOWER(CONV(murmur_hash_v3(CONCAT(column1, column2), 0), 10, 32));
它在大约 80% 的时间内与 php 版本匹配，这显然不会削减它。例如，哈希字符串 'engtest' 在 php 中创建 15d15m，在 MySql 中创建 3uqiuqa。但是，字符串“engtest sentence”在两者中创建了相同的散列。我做错了什么？
最佳答案
想通了。 PHP 的整数类型是有符号的，偶尔 Murmurhash 会产生与始终为正的 MySql 值不匹配的负散列值。解决方案是在基本转换之前使用 sprintf 将格式设置为“%u”来格式化 php 的哈希值。
$hash = murmurhash3_int($text);
return base_convert(sprintf("%u\n", $hash), 10, 32);
参见 php crc32 docs了解更多信息。
关于PHP Murmurhash3 和 MySql Murmurhash3 有时不匹配，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39638805/