Mysql 对于md5查找，最有效的索引类型和表引擎是什么？

我有一个包含几列的表，其中一列是md5哈希，它是表中的唯一键

为了确定表中是否已经存在哈希，最有效的引擎和索引类型（哈希/b树）是什么？我希望在200个分区中有数十亿行（mysql5.1）

现在我把它命名为myisam，在散列上有一个唯一的btree索引，但是我担心b-树的不断重新平衡会不断插入随机散列

伪代码：

if hash not in table:
  process
else:
  skip, record already exists

---

md5哈希有128位二进制。通常用32位的六位小数来写。 因此，查找任何字符字段并存储十六进制字符串（例如char 32）都是愚蠢的，只是简单而已。 您可以选择两个组合的bigint 64 unsigned，如果您需要某种排序，这将是很好的，而您不需要。 所以获胜者是： 二进制（16）。。。这正是你需要的

现在您应该使用哪个索引？ 这很难。从理论上讲，如果您有单独的和排他的相等运算符，那么使用散列索引可以更快。但问题是，btree几乎是独占使用的，您甚至不能在innodb中定义哈希。散列的实现可能是草率的。 事实上，没有太大的区别。btree更可靠

我更担心数据库引擎。myisam通常执行得更快，因为它缺少innodb具有的某些功能（例如回滚…），但它只有表锁定。inndbo可以执行行锁定，如果有大量更新和写入，它的性能可能会更好

好的。。。到现在为止，一直都还不错。现在我想建议您考虑使用与md5不同的东西。你到底为什么需要它？是否可以对crc和或更小的东西进行索引？我猜你正在查找文件并检查它们是否存在等等

最后。我会考虑整理你的数据库！ 切分基本上是一件棘手的事情，也是最后的手段，但在这种情况下，它可能相当容易

每一个以00结尾的东西都会进入服务器1、01->服务器2、10->3、11->4等（使用模运算，这是最快的！），以此类推。。。 如果您现在在数据库中检查md5哈希值，您就完全知道要查看哪个服务器，反之亦然，知道在哪里存储它！然后，您可以将数据拆分为任意多个服务器，您甚至不需要进一步复制它们，这样您就消除了任何瓶颈

当然，这取决于您的应用程序，我不知道还有哪些其他数据可以链接：）

您担心BTree索引的重新平衡，这意味着您有频繁的插入或更新，因此您应该避免MyISAM（由于表级锁定）

---

BTree是MyISAM/InnoDB唯一受支持的索引类型，您真的没有太多选择。如果使用InnoDB，请确保哈希值不是主键（由于聚集索引）

---

“如果使用InnoDB，请确保哈希不是主键（由于聚集索引）”。。。你能给我解释一下有什么问题吗？据我所知，dbms只是尝试使用键来存储数据，键之间的距离也很近。在这种情况下，这是没有用的，但我不认为这会使它明显变慢？我想说，对第二列进行索引会造成更大的性能损失（两个索引被计算、存储等）。。。但我可能错了。InnoDB使用聚集索引，行物理存储在索引的叶页中。由于MD5（或UUID）导致非顺序值，因此插入是随机的，这导致插入性能非常差。