我在 .Net 中可以在多大程度上依赖 GUID？
我在 .Net 中可以在多大程度上依赖 GUID？ 我的 SA 告诉我
我们将使用 GUID 作为所有表中的主键。
我想知道 GUID 作为主键的可靠性。
是否有可能出现重复？
我们真的应该使用这种方式吗？
性能怎么样？
任何建议都会对我有帮助。
How much I can rely on GUID in .Net ?
My SA told me that
we will use GUID as primary keys in all tables.
I wonder the reliability of GUID as a primary key.
Can there be any chances that there will be duplicate ?
Should we really use this way ?
How about the performance ?
Any advise would be helpful for me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
GUID 的一些要点可以为您提供答案
优势：
缺点：
您可以在以下位置阅读完整的帖子： SQL SERVER – GUID与 INT – 您的意见
This are some points for GUID which give you answer
Advantage:
Disadvantage:
You can read full post aobut this at : SQL SERVER – GUID vs INT – Your Opinion
您可能想看看这些文章：
http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
http://databases.aspfaq.com /database/what-should-i-choose-for-my-primary-key.html
就个人而言，如果我不需要主键在多个表和数据库中保持唯一，我会使用整数。我发现使用
87调试比2A734AE4-E0EF-4D77-9F84-51A8365AC5A0更简单。You may want to take a look at these articles:
http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
Personally I use integers if I don't need to have primary keys to be unique across several tables and databases. I find it simpler to debug with
87than2A734AE4-E0EF-4D77-9F84-51A8365AC5A0.是的，可能会有重复，但不会。 GUID 的长度为 32 个字符，每个字符可以是 0-F（十六进制）。这意味着 16^32 种可能性。
因此，如果您在 10 年内每秒生成 1 000 000 个 GUID，则创建重复项的机会约为 1 / 1079028307080601418897053。
在我看来，GUID 是一个非常好的主键候选者，因为您可以从任何地方生成 if 而无需先检查 if它已经存在于数据库中。
Yes, there can be a duplicate but it wont. The GUID is a 32 char long and each char can be 0-F (hexadecimal). That means 16^32 possibilities.
So if you generate 1 000 000 GUIDs every second for 10 years, the chance that you create a duplicate is around 1 / 1079028307080601418897053.
In my opinion a GUID is a very good primary key candidate as you can generate if from anywhere without first checking if it already exist in the database.
感谢生日悖论（问题），如果您生成，您大约有 50% 的机会找到重复的2^64 GUID...你高兴吗？ （这是因为完全随机的 GUID 长为 128 位，因此有 2^128 个不同的 GUID。生日悖论告诉我们，如果你有大约 sqrt(2^128) GUID，我说你有 50% 的机会发生冲突完全随机的 GUID，因为有一些标准类型的 GUID，其中一些数字是固定的，但 .NET 不使用这些标准（请阅读此处http://en.wikipedia.org/wiki/Globally_unique_identifier) ）
我会添加这一点，如果您问题是数据库“速度”的问题，您应该阅读以下内容：
提高集群索引 GUID 主键的性能
Thanks to the Birthday Paradox (Problem) you have around 50% of finding a duplicate if you generate 2^64 GUID... Are you happy? (this is because a fully random GUID is long 128 bits, so there are 2^128 different GUID. The birthday paradox tells us that if you have aproximatevely sqrt(2^128) GUID you have a 50% chance of a collision I say fully random GUID because there are some standard type of GUID where some digits are fixed. But .NET doesn't use these standards (read here http://en.wikipedia.org/wiki/Globally_unique_identifier) )
I'll add that if you problem is a problem of "speed" of the db, you should read this:
Improving performance of cluster index GUID primary key
在大多数情况下，您可以假设它们永远不会重复，如果您在表中的 ID 设置为主键，那么插入重复项无论如何都会出错。
在 Web 应用程序中使用这些 ID 的一个优点是，用户不能仅使用其他 ID 来测试 URL，因此理论上会更安全（尽管无论如何您都应该对服务器进行权限验证）
For the most part you can assume they will never duplicate, If your ID in a table is set to be the Primary Key, then inserting a duplicate will error anyway.
An advantage is using these ID's in a web application is that users cant just test URLS with other IDs so in theory would bemore secure (although you should have server validation for permissions anyway)
从统计上看，Guid 非常有可能是唯一的，因此，如果不同的系统生成 ID 并且所有这些系统都需要组合，那么它是主键的良好候选者。
例如。以离线模式工作并将更改推回到中央数据库。
Guids are statistically very highly likely to be unique and therefore are good candidates for primary keys if various systems are generating IDs and all of these need to be combined.
Eg. Working in an offline mode style and pushing back the change to the central db.