我有一个包含几列的表，其中一列是md5哈希，它是表中的唯一键。
为了确定表中是否已存在哈希，最有效的引擎和索引类型（哈希/ b树）是什么？我希望在200个分区（mysql5.1）上有数十亿行
现在我把它作为myisam，在该哈希列上有一个唯一的btree索引但是我担心b-tree的不断重新平衡，随机哈希被不断插入。
伪代码：
if hash not in table:
process
else:
skip, record already exists
答案 0 :(得分：2)
好md5哈希有128位二进制。将它们写成32位的十六进制小数是常见的。 所以去任何char字段并存储hexa十进制字符串（例如char 32）将是愚蠢的，只是简单的。 你可以选择两个合并的bigint 64 unsigned，如果你需要某种排序，这将是很好的 - 你不需要。 所以获胜者是： 二进制（16）...正好是128，正是你需要的。
现在你应该使用哪个索引？ 这是一个艰难的。从理论上讲，如果你只有完全相同的运算符，那么哈希索引可以更快。但问题是btree几乎是专门使用的，你甚至不能再在innodb中定义哈希。哈希的实现可能很草率。 和theres相差无几。 btree更可靠。
我会更担心数据库引擎。 myisam通常执行得更快，因为它缺少innodb具有的某些功能（例如回滚...），但它只有表锁定。 inndbo可以进行行锁定，如果你有很多更新和写入，它可能会表现得更好。
好的...到目前为止一切都那么好。现在我想建议考虑使用与md5不同的东西。为什么你需要它？是否可以索引crc总和或更小的东西？我猜你是文件并检查它们是否存在...最后。我会考虑分片你的数据库！ 分片大多是一种口号和最后的手段，但在这种情况下它可能非常容易。
以00结束的输送到服务器1,01->服务器2,10-> 3,11-> 4等（使用模运算，它是最快的！）等等...... 如果你现在检查数据库中的md5哈希，你确切知道要查看哪个服务器，反之亦然，在哪里存储它！那么你可以将你的数据库分成任意数量的服务器，你甚至不需要再进一步复制它们，这样你就可以消除任何瓶颈......当然，这取决于您的应用程序，我不知道可能链接的其他数据：）
答案 1 :(得分：0)
您担心BTree索引的重新平衡，这意味着您经常插入或更新，因此您应该避免使用MyISAM（由于表级锁定）。
BTree是MyISAM / InnoDB唯一支持的索引类型，你真的没有太多选择。如果你要使用InnoDB，请确保散列 NOT 主键（由于聚集索引）