GUID 与 int ID 自动递增
我正在尝试将我的设计敏感性从 LAMP 堆栈转移到 Microsoft 堆栈，我只是想到了一些事情 - 我什么时候想要使用 GUID？与旧的、可靠的自增 int 相比，它有什么优点/缺点？
I'm trying to shift my design sensibilities from the LAMP stack to the Microsoft stack, and I just thought of something - when would I want to use a GUID? What benefits/drawbacks does it have compared to the old, reliable auto-incremented int?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您从未需要过自动增量 id 之外的任何东西的经验可能表明 GUID 通常是寻找问题的解决方案。当您遇到熟悉的模式不起作用的需求时，请使用它们。微软性是无关紧要的。
我见过的唯一现实的场景是合并两个来源的表。
Your experience never having needed anything beyond autoincremental ids might suggest that GUIDs are often a solution in search of a problem. Use them when and if you ever run into a requirement where your familiar pattern doesn't work. The microsoftiness is irrelevant.
The only realistic scenario I've seen is merging tables from two sources.
“旧的、可靠的自动递增 int”在很大程度上取决于数据库需要的可扩展性。当您的设置至少有两个主设备时，自动递增在简单的情况下会停止工作。当然，解决这个问题并不太难，因为这是一个很常见的问题。不同的数据库引擎可以协调主设备之间的序列，例如只有一个主设备可以从任何给定序列进行分配。
当您对数据进行分片时，通常需要从键中了解分片。自动递增的 ID 不包含有关哪个分片应托管该记录的信息。
GUID 以不同的方式解决这个问题；两个不同的主机具有不同的主机标识符（通常是 MAC 地址）。由于它用于计算新的 GUID，因此不同的主机无法创建冲突的 GUID。此外，由于主机是ID的一部分，因此它可以用来直接识别保存记录的分片。
第三种选择是根本不使用代理键（既不使用自动增量整数也不使用 guid）。
"old, reliable auto-incremented int" depends rather strongly on just how scalable your database needs to be. Auto incrementing stops working in the trivial case when you have a setup with at least two masters. It's not too difficult to work around that, of course, because it's such a common problem; Different database engines may coordinate the sequence between the masters, for instance only one master may allocate from any given sequence.
When you get into sharding the data, it's normally desirable to know the shard from the key. An auto incremented id doesn't contain information about which shard should host that record.
GUID's solve the problem in a different way; two distinct masters have distinct host identifiers (typically a MAC address). Since that is used in computing a new GUID, distinct masters cannot create guid's that collide. Furthermore, since the host is part of the ID, It can be used to directly identify the shard that holds the record.
A third option is to use no surrogate keys at all (neither auto increment integers nor guids).
GUID 的一个问题是：
由于它们不是连续的，因此数据库必须努力更新索引。对于顺序 id，通常可以将其附加到末尾（或多或少）。由于 GUID 是随机的，因此必须将其放入现有块中。也就是说，我们对某些表使用 GUID，即使在相当重的负载下，它们似乎也能正常工作。
One problem with GUIDs:
Because they are not sequential, the database will have to work hard to update indexes. With a sequential id, it can usually just append it to the end (more or less). Since GUIDs are random it has to fit it into an existing block. That said, we use GUIDs for some tables and they seem to work fine even under fairly heavy load.
我建议使用 int ID 而不是 Guid，原因如下：
I would recommend to use int ID instead of Guid for the following reasons: