sql-server-2008 - EF 4.0 Guid或Int作为主键

Question

我正在使用EF 4.0实现自定义ASPNetMembership

有什么原因为什么我应该在用户表中使用Guid作为主键？

据我所知，Int作为SQL Server上的PK比字符串更有效。

而且Int更容易迭代。
同样，出于安全目的，如果我需要在某个地方传递任何int id，例如在url中，我可以以某种方式对其进行加密并将其像没有问题的字符串一样传递。

但是，如果我想在使用EF 4.0的SQL Server端上使用自动生成的Guid，我需要做这个技巧http://leedumond.com/blog/using-a-guid-as-an-entitykey-in-entity-framework-4/

我看不到任何情况，为什么我应该使用Guid作为PK，如果系统要拥有数百万和数百万的用户，可能只是一个例子，而且，从理论上讲，可以在某个时候复制Guid不是吗？

无论如何，Int32的大小是2,147.483.647，即使对于非常大的系统也是如此，但是如果这个数目仍然不够，我可以使用Int64，在这种情况下，我可能有9,223.372.036.854.775.807行。差不多吧？

另一方面，M $在其ASPNetMembership实现中使用Guids作为PK。 [aspnetdb]。[aspnet_Users]-> PK UserId类型uniqueidentifier，
应该是为什么的原因/解释吗？!

可能有人对此有任何想法/经验吗？

Answer 1

我会百分百同意您-使用INT IDENTITY会更好!

GUID似乎是您的主键的自然选择-如果确实需要，您可能会争辩说将其用于表的PRIMARY KEY。我强烈建议不执行的做法是，将GUID列用作群集键，默认情况下，SQL Server会执行此操作，除非您明确指示不这样做。

您确实需要将两个问题分开:

1)主键是一个逻辑结构-唯一且可靠地标识表中每一行的候选键之一。实际上，这可以是任何东西-INT，GUID，字符串-选择最适合您的方案的东西。

2)集群键(在表上定义“集群索引”的一列或多列)-这是与物理存储相关的事情，在这里，小型，稳定，不断增长的数据类型是您的最佳选择-INT或BIGINT作为默认选项。

默认情况下，SQL Server表上的主键也用作群集键-但这不是必须的!当我将以前基于GUID的主键/集群键分解为两个单独的键时，我个人已经看到了巨大的性能提升-GUID上的主(逻辑)键和单独的INT IDENTITY(1， 1)栏。

正如Kimberly Tripp(索引女王)和其他人已经说过很多次一样，GUID作为聚类键并不是最佳的，因为它的随机性，它将导致大量的页面和索引碎片，并且通常会导致性能下降。

是的，我知道-SQL Server 2005及更高版本中存在newsequentialid()-但这甚至不是真正且完全顺序的，因此也遭受了与GUID相同的问题-不太明显。

然后还有一个要考虑的问题:表上的集群键也将添加到表上每个非聚集索引的每个条目中，因此，您真的要确保它尽可能小。通常，具有2+十亿行的INT应该足以容纳绝大多数表-与GUID作为集群键相比，您可以在磁盘和服务器内存中节省数百兆的存储空间。

快速计算-使用INT vs. GUID作为主键和聚类键:

带有1'000'000行的

基本表(3.8 MB与15.26 MB)

6个非聚集索引(22.89 MB vs.91.55 MB)

总计:25 MB和106 MB -那就在一张 table 上!

再想一想-金伯利·特里普(Kimberly Tripp)的优秀著作-读它，再读一次，消化它!确实，这是SQL Server索引的福音。

GUIDs as PRIMARY KEY and/or clustered key

The clustered index debate continues

Ever-increasing clustering key - the Clustered Index Debate..........again!

Disk space is cheap - that's not the point!