字符串作为主键的性能损失？

Question

使用字符串作为主键而不是bigints等会有什么性能损失？字符串比较比整数比较昂贵得多，但另一方面，我可以想象在内部DBMS将计算散列键以减少惩罚。

我工作的应用程序在多个表（MySQL）中使用字符串作为主键。改变这一点并非易事，我想知道可以通过哪些方式获得合理的工作。

Answer 1

  另一方面，我可以想象   在内部，DBMS将计算哈希值   减少惩罚的关键。

数据库需要使用密钥维护 B-Tree （或类似结构），以便对它们进行排序。

如果密钥被散列并存储在B-Tree中，可以快速检查密钥的唯一性 - 仍然可以有效地查找密钥。但是您无法有效搜索范围数据（例如，使用LIKE），因为根据字符串值不再对B树进行排序。

所以我认为大多数DB确实将字符串存储在B树中，它可以（1）比数值更多空间和（2）要求B-Tree 如果以任意顺序插入键，则重新平衡（没有像数字pk那样增加值的概念）。

惩罚在实践中可以从微不足道到巨大的。这一切都取决于用法，行数，字符串键的平均大小，连接表的查询等。

Answer 2

在我们的产品中，我们使用varchar（32）作为主键（GUID），我们还没有遇到性能问题。我们的产品是一个极端过载的网站，对于稳定至关重要。 我们使用SQL Server 2005。

编辑：在我们最大的表中，我们有超过3 000 000条记录，其中包含大量插入和选择。我认为一般来说，迁移到int key的好处将非常低，但迁移时的问题非常高。

Answer 3

这取决于几个因素：RDBMS，涉及这些列的索引数量，但一般来说使用整数会更有效率，其次是bigint。

任何性能提升都取决于使用情况，因此如果没有表模式和查询工作负载的具体示例，很难说。

除非在域中有意义（我认为像社会安全号这样的独特之处），否则代理整数键是一个不错的选择;当引用的对象发生更改时，引用对象不需要更新其FK引用。

Answer 4

需要注意的一件事是页面拆分（我知道这可能发生在SQL Server中 - 在MySQL中可能是相同的）。

主键是物理排序的。通过使用自动增量整数，您可以保证每次插入时都插入下一个数字，因此db不需要重新排序键。但是，如果使用字符串，则可能需要将插入的pk放在其他键的中间以保持pk顺序。重新排序插件上的pks的过程可能会变得昂贵。