我有一个可能包含1000万个以上唯一键的Dictionary<string,int>。我想尽量减少内存使用，同时仍然保持字典的功能。
我的想法是将字符串的哈希值作为长整型存储，这样可以将应用程序的内存使用减少到可接受的水平（从约1.5 GB降至约0.5 GB），但我对自己的方法感到不太满意。
long longKey=
BitConverter.ToInt64(cryptoTransformSHA1.ComputeHash(enc.GetBytes(strKey)), 0);
Dictionary<long,int>，其中long是字符串的哈希函数的结果。我最近做了类似的事情，由于我的应用程序有一些独特的原因，我没有使用数据库。事实上，我试图停止使用数据库。我发现，在3.5版本中，GetHashCode显著改进了。一个重要的注意点是，永远不要持久地存储从GetHashCode得到的结果。千万不要这样做。它们不能保证在框架版本之间保持一致。
因此，您确实需要对数据进行分析，因为不同的哈希函数可能在您的数据上表现更好或更差。您还需要考虑速度。作为一般规则，即使哈希值数量达到数十亿，加密哈希函数也不应该有太多冲突。对于我需要唯一性的东西，我通常使用SHA1 Managed。总的来说，CryptoAPI的性能非常糟糕，即使底层哈希函数表现良好。
对于64位哈希，我目前使用Lookup3和FNV1，它们都是32位哈希，结合在一起使用。为了发生冲突，两者都需要发生冲突，这在数亿个哈希中是数学上不可能的，而我也没有看到在大约1亿个哈希中出现过。您可以在网络上公开找到这两个哈希函数的代码。
仍然要进行自己的分析。对我有效的方法可能对您无效。实际上，在我的办公室里，不同的应用程序具有不同的要求，使用不同的哈希函数或哈希函数组合。
我建议避免使用未经证明的哈希函数。与认为自己应该编写它们的人一样多的哈希函数。请做好研究和测试测试测试。
你是否考虑使用带有非聚集索引的数据库来处理1000万条记录？对于这种情况，数据库有更多的技巧。
根据定义和任何算法，哈希都有可能发生碰撞，特别是在高负载情况下。根据场景，我会非常谨慎地使用它。
使用字符串可能需要占用空间，但是它是可靠的……如果你使用x64，那么这不需要太大的空间（尽管它肯定算得上“大”;-p）。
GetHashCode()来获取字符串的哈希值？只需获取SQLite。您不太可能超越它，即使您这样做，也可能不值得花费时间/精力/复杂性。
SQLite。
在我以前使用的哈希表实现中，哈希会带您进入存储有相同哈希值的其他对象的链接列表的桶中。哈希值不是唯一的，但足以将数据分成易于管理的列表（有时只有2或3个元素），然后您可以搜索这些列表以找到实际的项。
一个好的哈希的关键不在于它的唯一性，而在于它的速度和分布能力......您希望它尽可能均匀地分布。