忘记术语“最佳”。不管有人会提出哪种哈希算法，除非您需要对哈希数据进行限制的数据集非常少，否则，如果只接受正确的算法（或从您的角度来看），则平均而言性能出色的每种算法都将变得完全无用。
“错误”）数据。

与其浪费太多时间来思考如何在不使用过多CPU时间的情况下使散列更无冲突，不如将其浪费在思考如何减少冲突问题上。例如，如果每个哈希存储桶实际上都是一个表，并且该表中所有发生冲突的字符串按字母顺序排序，则可以使用二进制搜索（只有O（log
n））在存储桶表中进行搜索，这意味着，即使每个第二个哈希存储桶发生4次冲突，您的代码仍将具有不错的性能（与无冲突表相比，它会慢一些，但不会那么多）。这里的一大优势是，如果您的表足够大并且哈希值不太简单，

实际上，我本人之前就遇到过这样的情况：使用二进制搜索直接在排序的表中搜索比散列要快！尽管我的哈希算法很简单，但是哈希值还是花了很多时间。性能测试表明，只有获得超过700-800个条目，散列的确比二进制搜索快。但是，由于该表无论如何都不能增长到大于256个条目，并且由于平均表低于10个条目，因此基准测试清楚地表明，在每个系统，每个CPU上，二进制搜索都更快。在这里，通常已经比较了数据的第一个字节足以导致下一次bsearch迭代（因为数据在第一个到两个字节中已经非常不同）这一事实被证明是一个很大的优势。

综上所述：我将采用一种不错的哈希算法，该算法平均不会导致太多的冲突，并且速度非常快（如果速度非常快，我什至会接受更多的冲突！）并优化我的代码以便在发生冲突时获得最小的性能损失（而且将会！！除非您的哈希空间至少等于或大于数据空间，并且您可以将唯一的哈希值映射到每个可能的数据集，否则它们将）。