适配PostgreSQL UUID类型的低碰撞128位哈希算法选型建议

针对你的需求——用128位UUID类型存储哈希、替代长字符串、优先低碰撞率（不关心安全性），以下是对各算法的分析和推荐：

核心前提 #

碰撞概率的核心是哈希值的分布均匀性，只要算法能让哈希值在128位空间内均匀随机分布，理论上的随机碰撞概率就遵循生日悖论：128位空间下，要达到50%碰撞概率需要约2^{64条记录，百万级（10}6）记录的碰撞概率几乎可以忽略不计。我们的目标是选分布最均匀、实际碰撞风险最低的算法。

各算法分析 #

• MD5：
  你提到的“未充分利用128位空间”是误解——MD5的128位输出完全用于哈希值，没有预留控制段。但MD5存在人为构造碰撞的可能（不过你不关心安全性，这个可以忽略）。从随机碰撞概率来看，它的分布均匀性尚可，但相比现代算法没有优势，不推荐作为优先选择。

• MurmurHash3（128位版本）：
  专为非加密场景设计的高性能哈希，核心优势就是极高的分布均匀性和低碰撞率，同时计算速度极快。它的128位输出完全适配UUID类型，在百万级甚至更高量级的记录中，实际碰撞风险可以认为是0，非常适合你的场景。

• SHA-3（截取128位）：
  SHA-3是加密级哈希算法，设计时就严格保证了哈希值的均匀随机性。不管截取它256位/512位输出的前128位还是后128位，得到的哈希值分布都接近理想的随机128位哈希，理论碰撞概率是所有选项中最接近下限的。缺点是计算性能比MurmurHash这类非加密哈希差一些，但如果你的计算量不是极端大，这个差异可以接受。

• xxHash128：
  另一款优秀的非加密高性能哈希，和MurmurHash3 128位类似，分布均匀性出色，碰撞率极低，性能甚至略优于MurmurHash，也是非常合适的选择。

最终推荐 #

1. 若追求极致低碰撞率+理论可靠性：优先选SHA-3截取128位（比如取SHA3-256的前128位），加密哈希的设计保证了最均匀的分布。
2. 若追求低碰撞率+高性能：选MurmurHash3 128位或xxHash128，完全满足百万级记录的需求，计算速度更快。

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