有什么理由我应该使用Guid作为用户表中的主键吗？
据我所知,Int作为sql Server上的PK比字符串表现得更好.
而且Int更容易迭代.
另外,出于安全目的,如果我需要在某个地方传递任何int id,例如在url中我可能以某种方式加密它并将其传递为没有probs的字符串.
但是,如果我想使用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,
应该是一些原因/解释为什么这样做？！
可能有人对此有任何想法/经验吗？
解决方法
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相同的问题 – 只是不那么突出.
然后还有另一个需要考虑的问题：表格上的聚类键也会被添加到表格中每个非聚集索引的每个条目上 – 因此您确实希望确保它尽可能小.通常,具有20亿行的INT应该足以用于绝大多数表 – 并且与作为群集密钥的GUID相比,您可以在磁盘和服务器内存中节省数百兆字节的存储空间.
快速计算 – 使用INT与GUID作为主要和群集密钥：
>基准表,1’000’000行(3.8 MB对15.26 MB)
> 6个非聚簇索引(22.89 MB对91.55 MB)
总计：25 MB对106 MB – 这只是在一张桌子上！
还有一些值得深思的东西 – 金佰利特里普的优秀作品 – 阅读,再读一遍,消化它！这是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!
