作为主键的字符串的性能惩罚?

另一方面,我可以想象 在内部,DBMS将计算哈希 减少处罚的钥匙。

数据库需要保持 B-树 (或类似的结构)用钥匙按顺序排列。

如果密钥被散列并存储在B树中,那么可以快速检查 唯一性 关键点——关键点仍然可以被有效地查找。但是你不能有效地搜索 范围 数据(例如 LIKE )因为B-树不再按照字符串值排序。

所以我认为大多数数据库确实将字符串存储在B树中,这需要(1)更多 空间 而(2)要求B-树 再平衡 如果以任意顺序插入键(没有增加值的概念,如使用数字pk)。

这个 处罚 实际上,范围从微不足道到巨大。这都取决于用法、行数、字符串键的平均大小、连接表的查询等。

在我们的产品中,我们使用varchar(32)作为主键(guid),但我们还没有遇到性能问题。我们的产品是一个超负荷的网站,对稳定至关重要。 我们使用SQL Server 2005。

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

需要注意的一件事是页面拆分(我知道这可能发生在SQL Server中——可能在MySQL中也是如此)。

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

它取决于几个因素:RDBMS、涉及这些列的索引的数量,但一般来说,使用int会更有效,bigints会遵循这一点。

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

除非它在域中有意义(我认为它是唯一的,比如社会保险号),否则代理整数键是一个不错的选择;引用对象不需要在引用对象更改时更新其FK引用。