UUID和MD5以及其他散列很糟糕，因为；随机性"；以及缺乏"；参考位置">不是，因为它是字符而不是数字。
您可以将它们转换为BINARY(16)，从而使它们的大小减半。
10M INT = 40MB = 600/block
10M CHAR(32) = 320MB = 300/block
10M VARCHAR(32) = 330MB = 300/block
10M BINARY(16) = 160MB = 450/block
为该表中的每个辅助关键字添加更多。
为引用该PK的每个其他表(例如，FOREIGN KEY(再次添加。
让我们看看B+树，它是PK和二级索引的结构。在16KB的块中，可以放置一定数量的条目。我已经估计过了。(是的，"开销"比INT大得多。(对于INT，10M行的BTree可能有3级深度。其他人也是如此。(随着表格的增长，Varchar将在其他级别之前移动到4个级别。(
因此，我得出结论，需要多少BTree块来完成您的"；点查询"；。
字符串比INT:慢多少的摘要
- B树深度——很少或没有
- 索引块的可操作性——一些；不是很大
- 比较数字和字符串的CPU时间——有些；不是很大
- 使用花哨的
COLLATION——一些；不是很大
总体而言——没有足够的差异值得担心。
在某些情况下，我会争论的是你是否需要一个捏造的PK。在我构建的2/3的表中，我发现有一个"自然"的PK——一些列，根据业务逻辑，自然是UNIQUE和NOT NULL。这是PRIMARY KEY的两个主要条件(在MySQL中(。在一些情况下；天然PK"；可以是大于2的因子。
多对多映射表就是一个很好的(也是常见的(例子。
不可能说出检索特定记录所需的确切时间，因为这取决于许多因素。
通常，数值占用的存储空间较小，因此扫描索引所需的I/O操作较少，因此通常速度较快。
然而，在这种特定情况下，第二个表看起来像是一个大数字的十六进制表示。您可以将其存储为二进制值以节省存储空间。
除此之外，通常情况下，数值不受各种数据库和列设置的影响，而字符串则(如排序规则(，这也会在查询时增加一些处理时间。
真正的问题是使用二进制表示的目的是什么。1000万个值可以很容易地放入INT中。需要一个可以存储更多(32长十六进制值(的密钥吗？
只要您在数值的范围内，并且没有其他要求，只要能够存储那么多不同的值，我就会使用整数。
你在问题中提到的"问题"通常不是问题。在大多数caes中，没有必要在标识符中不存在空白。事实上，在许多系统中，间隙是在正常操作过程中自然发生的。当从表中间删除一条记录时，您很可能不会将记录重新分配给其他ID。
除非ID有语义含义(不应该有(，否则我只会使用AUTO_INCREMENT，没有必要重新发明轮子。