我知道 GUID 在理论上是独一无二的，碰撞的可能性非常低。但是，如果我理解正确，一些唯一性是可用的，因为它是从用于生成它的计算机上的信息中播种的，具体取决于所使用的算法。
给定一个 GUID，用户猜测表中其他 GUID 的可能性有多大？
例如，如果您的时事通讯订阅者具有取消订阅功能，您可以将其发布到 example.com/subscriber/unsubscribe/{id}
对于整数身份，这显然是一个坏主意。ID 为 1000 的用户可以通过猜测 ID 在几秒钟内取消订阅您的整个数据库。
如果 ID 列是初始化为 newid() 的 GUID，您的用户在知道自己的 ID 的情况下猜出正确 ID 的可能性有多大？
我会说这在理论上可能是可能的，但实际上非常非常不可能发生。
我已经阅读了 SLaks 在他的评论中链接的 Eric Lippert 的博客文章，以及 Stack Overflow 上的其他一些答案：
据我了解：给定一组几个 GUID，有可能找出它们是否是在同一台机器上生成的。但这并不容易找到，而且对于普通用户来说肯定不是。
现在我猜如果只给定一个GUID（示例中的时事通讯订阅 ID），就很难猜出任何其他 GUID。
如果（且仅当）真的有可能，您可能需要一台快速的机器和对用于创建 GUID 的算法的深入了解。
最后，您必须查看上下文：
即使可以猜测 GUID（我也不确定是否 - 我确定我做不到），我无法想象有人真的会这样做，以便从您的时事通讯中取消订阅其他人。
NEWID() 生成一个版本 4 GUID，但它的实现是可以猜测的。GUID 被设计为唯一的，而不是随机的。
来自 RFC 4122 规范：
安全注意事项
不要假设 UUID 很难猜；例如，它们不应该用作安全功能（仅拥有授予
访问权限的标识符）。一个可预测的随机数源会
加剧这种情况。
正如@martin-smith 指出的那样，仅仅因为它是第 4 版投诉 GUID 并不能使其本质上是可猜测的，它取决于实现。这篇 stackexchange 帖子展示了如何使用不可猜测的 SQL 创建投诉版本 4 GUID：
SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)
参考：