字符串作为SQL数据库中的主键

我不熟悉数据库及其工作原理.从性能角度(插入/更新/查询)到主键使用字符串比整数更慢吗？

1> kemiller2002..：

---

从技术上讲是的,但如果一个字符串有意义成为主键,那么你应该使用它.这一切都取决于您所使用的表的大小以及将成为主键的字符串的长度(较长的字符串==难以比较).对于具有数百万行的表,我不一定会使用字符串,但是通过在较小的表上使用字符串而获得的性能减慢量对于通过使用不包含整数的整数而言可能会有一些麻烦不是指与数据有关的任何内容.

---

它不会依赖于数据库吗？我认为一个正确的索引字符串,如果有一个数字,会不会那么慢？

---

还要记住,在进行索引比较时,CHAR和VARCHAR之间通常存在很大差异

---

这个答案的评论数量清楚地表明它是多么不完整.提及索引可能是最低可接受的答案.

---

我同意有很多变量需要考虑.(在sqlserver中)我们已经看到使用长度在中等到高的青少年及以上的字符串的真正性能问题,即使在索引时也是如此.买你是对的有东西要克服这个硬件,例如.

2> Jeff Martin..：

---

使用字符串作为主键的另一个问题是,因为索引始终按顺序排列,当创建一个新键时,该键将处于顺序中间,索引必须重新排序...如果使用自动数字整数,新键只是添加到索引的末尾.

---

这是主键聚集的时候.你也可以创建它们unclustered.

3> 小智..：

---

插入到具有聚簇索引的表中,其中插入发生在序列的中间,不会导致索引被重写.它不会导致包含数据的页面被重写.如果页面上有空间,那么它将被放置在该页面中.将重新格式化单个页面,以将行放在页面中的正确位置.当页面已满时,将发生页面拆分,页面上的一半行转到一页,另一半转到另一页.然后将页面重新链接到包含具有聚簇索引的表数据的页面的链接列表中.最多,您最终将编写2页数据库.

4> HLGEM..：

---

字符串在连接中较慢,在现实生活中它们很少是真正独特的(即使它们应该是这样).唯一的好处是,如果您只是为了获取名称而加入主表,它们可以减少连接数.但是,字符串也经常会发生变化,从而产生在公司名称发生变化或结婚时必须修复所有相关记录的问题.这可能是一个巨大的性能损失,如果所有应该以某种方式相关的表都不相关(这种情况比您想象的更频繁),那么您可能也会遇到数据不匹配.从数据完整性的角度以及从性能的角度来看,一个永远不会在记录生命周期内改变的整数是一个更安全的选择.自然键通常不太适合维护数据.

我还想指出,两个世界中最好的通常是使用自动增量键(或在某些特殊情况下,GUID)作为PK,然后在自然键上放置一个唯一索引.您获得更快的连接,您不会获得重复的记录,并且您不必更新一百万个子记录,因为公司名称已更改.

---

作为PK的良好候选者的字符串没有重复 - 否则他们不会是PK的好候选者.想想ICD-9代码,国家代码,VIN#.使用名称作为自然键问题的一个例子是错误的,因为它们永远不应该成为候选者.

---

@Tom H:ISO县代码DO改变.[http://en.wikipedia.org/wiki/ISO_3166-1#Editions_and_changes]作为对相关问题的回答说[http://stackoverflow.com/questions/925266/database-design-and-the-use- of-non-numeric-primary-keys/925290#925290]"对于PRIMARY KEY来说,确保它们的独特性在你的控制之下"

---

@SteveSchnepp:是的,ISO是管理这种变化的可靠机构.另一方面,当你需要将你的单调递增整数值序列与其他人合并时,你就是你自己;)

5> Al Katawazi..：

---

只要它是独一无二的,你使用什么作为主键并不重要.如果您关心速度或良好的数据库设计,请使用int,除非您计划复制数据,然后使用GUID.

如果这是一个访问数据库或一些小应用程序,那么谁真正关心.我认为我们大多数开发人员在前面使用旧的int或guid的原因是因为项目有一种在我们身上成长的方式,并且你想让自己成长.

6> Joel Coehoor..：

---

变量太多。它取决于表的大小，索引，字符串键域的性质...

通常，整数会更快。但是差异会足够大吗？很难说。

另外，您选择弦乐的动机是什么？数字自动增量键通常也非常容易。是语义吗？方便？复制/断开连接的担忧？您在这里的答案可能会限制您的选择。这也让您想到了您忘记的第三个“混合”选项：指导。