SQL主键，使用INT还是GUID或其他方式？

Question

10

我是否应该使用整数作为表的主键？

数据库是SQL-CE，有两个主要表，每年约有50000条记录，以及几个较小的表。只有两个连接将不断开放到数据库。但是通过多个TCP套接字连接触发更新，因此许多跨线程访问和使用相同的数据库连接。尽管活动非常低，因此同时更新的可能性相当低，但最多可能会发生几次每天。

可能会使用LINQ2SQL进行数据访问层（DAL）或类型化数据集。

不确定这些信息是否相关，但这就是我为什么在问，因为我不知道 :)

- bretddog

5个回答

9

使用GUID作为主键的优势在于它应该是世界上唯一的，例如将数据从一个数据库移动到另一个数据库。所以您知道行是唯一的。

但如果我们谈论的是小型数据库，我更喜欢使用整数。

编辑：

如果您使用SQL Server 2005++，还可以使用NEWSEQUENTIALID()，这将基于上一行生成一个GUID。允许消除newid()的索引问题。

- eriksv88

4

建议使用 GUID，这与所有的证据都相反。那么，那些引用聚集索引的非聚集索引呢？ - gbn

他在第二段建议使用整数。我接受了这个答案，因为理解GUID的目的让我看到为什么我不需要它。但是这里所有的答案都很有帮助且切中要点。谢谢！ - bretddog

它不一定是唯一的，只是很可能是唯一的。 - Anthony Johnston

@gbn：我知道你通常反对使用GUID。然而，在包含1亿条以上记录的数据库中，我们广泛使用它们。猜猜怎么着..这个数据库非常快。我看到的反对意见并没有得到证实，而GUID提供的灵活性在使我的生活更轻松方便方面产生了回报。 - NotMe

@ChrisLively：我偶尔使用GUID。但很少作为聚集索引，而且从不处理非常高的写入量（每分钟数百万行）。页面分裂和增加宽度带来的额外开销通常意味着“不要使用GUID”。我不是唯一的支持者：请参见其他答案和评论... - gbn

显示剩余3条评论

5

我是否应该使用整数作为我的表的主键？

只要每个整数是唯一的，就可以使用整数作为主键，没有问题。Guids 一开始听起来是一个不错的主意，但实际上它们太大了。大多数情况下，这就像用大锤打死一只苍蝇，Guid的大小使得它比使用整数慢得多。

- kemiller2002

2

你能提供证据证明GUID会使数据库变得更慢吗？ - oɔɯǝɹ

5

我认为在这种情况下使用自增整数是没有理由不用的。如果你到达了整数无法处理数据量的点，那么你所说的应用程序已经扩展到需要更多工作的程度了。

请记住以下几点：

1.整数是硬件的本机字大小。它是计算机上最快速、最简单和最容易的数据类型之一。

2.当考虑可能使用GUID时，请知道它们会成为可怕的主键。关系数据库一般来说（我不能代表所有人，但MS SQL是一个很好的例子）不会很好地索引GUID。有一些黑客方法可以尝试使GUID更易于索引，接受或离开它们。但通常出于性能原因应避免将GUID用作PK。

- David

2

很有趣，因为我经常看到微软在使用GUID作为主键。例如，Microsoft CRM使用GUID作为其主键之一。 GUID的一个优点是您不必担心排序，并且除非您以某种方式重用先前的密钥，否则不可能出现密钥冲突。 - Erik Funkenbusch

1

@Mystere Man：嗯，它很不可能出现关键冲突 :) 但你的观点仍然存在，并且这是我从未理解过的一些微软工具的问题。他们为ASP .NET提供的成员身份/角色提供程序是一个常见的例子。像这样的东西在小项目中可能运行良好，但它不会扩展。 - David

4

一定要使用整数，在集群索引（PK）中不要使用GUID，因为这会导致表格不必要地碎片化。

- Josh Weatherly

2

主键不一定要成为聚集索引。 - HLGEM

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Oded · Accepted Answer

你应该使用整数 - 整数更小，意味着占用的内存更少，IO（磁盘和网络）更少，在连接时需要处理的工作也更少。

数据库应该处理并发问题，无论主键类型为何。