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

Question

使用字符串代替bigints等作为主键的性能损失是多少？ 字符串比较比整数比较昂贵得多，但是另一方面，我可以想象DBMS在内部将计算哈希键以减少代价。

我使用的应用程序使用字符串作为几个表的主键（MySQL）。 改变这一点并不容易，我想知道可以从性能上获得什么来证明这项工作合理。

Answer 1

另一方面，我可以想象DBMS在内部将计算哈希键以减少代价。

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

如果对密钥进行哈希处理并将其存储在B树中，则可以快速检查密钥的唯一性 -仍然可以有效地查找密钥。 但是您将无法高效地搜索数据范围 （例如，使用LIKE ），因为B-Tree不再根据String值进行排序。

因此，我认为大多数DB确实将字符串存储在B树中，这可能（1）比数字值占用更多的空间 ，并且（2）如果以任意顺序插入键，则B树必须重新平衡 （无概念）与数字pk一样的增加值）。

在实践中的罚款范围从微不足道到巨大。 这完全取决于用法，行数，字符串键的平均大小，连接表的查询等。

Answer 2

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

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

Answer 3

它取决于几个因素：RDBMS，涉及这些列的索引数，但通常使用bigints所支持的int会更有效。

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

除非在域中有意义（我认为是唯一的东西，例如社会保险号），否则替代整数密钥是一个不错的选择； 引用对象发生更改时，引用对象无需更新其FK引用。

Answer 4

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

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