我认为在您的情况下使用 GUID 是更好的选择。它占用更多空间，但更安全。
9 个回答
我认为这是引起准宗教辩论的问题之一，谈论它几乎是徒劳的。我只想说使用你喜欢的。在 99% 的系统中，无论您使用哪种类型的密钥，都不会出现问题，因此使用一种密钥的好处（在其他帖子中说明）永远不会成为问题。
我可以回答您，在 SQL Server 中，如果您使用唯一标识符 (GUID) 数据类型并使用 NEWID() 函数创建值，您将由于页面拆分而获得可怕的碎片。原因是使用 NEWID() 时生成的值不是顺序的。 SQL 2005 添加了 NEWSEQUANTIAL() 函数来解决这个问题
仍然使用 GUID 和 int 的一种方法是在表中有一个 guid 和一个 int，以便 guid 映射到 int。 guid 在外部使用，但在 DB 内部使用 int
例如
457180FB-C2EA-48DF-8BEF-458573DA1C10 1
9A70FF3C-B7DA-4593-93AE-4A8945943C8A 2
1 和 2 将用于连接和 Web 应用程序中的 guid。这个表会很窄，查询起来应该很快
您可以使用与行号相关但不连续的整数。例如，您可以采用顺序 ID 的 32 位并使用固定方案重新排列它们（例如，位 1 变为位 6，位 2 变为位 15，等等）。
这将是一种双向加密，您将确保两个不同的 ID 将始终具有不同的加密。
如果您花时间生成足够的 ID 并获取架构，显然很容易解码，但是，如果我正确理解您的问题，您只是不想太容易泄露信息。
而不是像这样的网址：
http://example.com/user/783
为什么没有：
http://example.com/user/yukondude
哪个对人类更友好并且不会泄露那一点点信息？
就其价值而言，我已经看到一个长时间运行的存储过程（9 秒）只需从 GUID 主键切换到整数，运行时间就会减少到几百毫秒。这并不是说显示一个 GUID 是一个坏主意，但正如其他人指出的那样，根据定义，加入它们并为它们编制索引不会像使用整数那样快。
我不能说你问题的网络方面。但是 uuid 非常适合 n 层应用程序。 PK 生成可以是分散的：每个客户端生成自己的 pk，没有冲突的风险。 且速度差异一般较小。
确保您的数据库支持高效的存储数据类型（16 字节、128 位）。 至少你可以用 base64 编码 uuid 字符串并使用 char(22)。
我已经将它们广泛用于 Firebird 并且推荐。
我们使用 GUID 作为所有表的主键，因为它兼作 MS SQL Server 复制的 RowGUID。当客户突然在世界的另一个地方开设办事处时，这很容易...
我使用一个使用整数形式的 UUID 的学生管理系统。他们有一个表，用于保存下一个唯一 ID。
虽然从架构的角度来看这可能是一个好主意，但它使日常工作变得困难。有时需要进行批量插入，而拥有 UUID 会使这变得非常困难，通常需要编写游标而不是简单的 SELECT INTO 语句。