如何选择适合作为MySQL唯一索引的字符串哈希算法？

结合你要导入100GB+数据、生成哈希作为MySQL唯一索引的场景，咱们逐个拆解三个选项的适配性：

1. 绝对避开：string.hashCode() #

• 这个方法生成的是32位整数，碰撞概率极高——面对海量数据条目，几乎一定会出现不同字符串生成相同哈希的情况，直接导致唯一索引冲突，数据插入失败。
• 哪怕忽略碰撞问题，它的取值范围有限（-2^31到231-1），完全不适合作为唯一标识。

2. 可选但有局限：UUID.nameUUIDFromBytes(string.getBytes()) #

• 这是基于MD5哈希生成的UUID v3，输出是128位的36字符字符串（带连字符），碰撞概率远低于hashCode()，但MD5已被证实存在人为构造碰撞的可能（自然碰撞概率仍极低）。
• 关键提醒：一定要指定统一字符编码！比如改成UUID.nameUUIDFromBytes(string.getBytes(StandardCharsets.UTF_8))，否则不同环境下默认编码差异会导致相同字符串生成不同UUID，破坏一致性。
• 从MySQL索引性能看，36字符的字符串索引比整数慢，但比SHA256的短字符串好一些；不过对于超大量数据，仍存在极小的碰撞风险需要考量。

3. 最推荐：org.apache.commons.codec.digest.DigestUtils.sha256Hex(string) #

• SHA256是256位加密哈希，目前没有已知的自然碰撞案例，碰撞概率在你的数据规模下几乎可以忽略，完全满足唯一索引的核心要求。
• 输出是固定长度的64位十六进制字符串，MySQL对固定长度字符串的索引支持稳定；虽然比UUID长，但现代数据库足以应对，这点性能损耗在唯一性保障面前完全值得。
• 同样要注意编码一致性：如果底层依赖字符串转字节，确保使用统一编码（比如UTF-8），避免环境差异导致哈希不一致。

额外优化建议 #

如果担心SHA256字符串太长，也可以取哈希结果的前16个字节（转成32位十六进制字符串），碰撞概率仍远低于UUID，同时缩短了索引长度，兼顾性能与唯一性。

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