Database 要使用哪种类型的数据库记录id：long还是guid？

最近几年，我使用的是MSSQL数据库，表中的所有唯一记录的ID列类型都是bigint（long）。它是自动递增的，通常工作正常

目前，我观察到人们更喜欢使用guid作为记录的标识

将bigint与guid交换为唯一记录id有意义吗

我认为这没有意义，因为生成bigint和排序总是比guid快，但是。。。当使用两个（或更多）分离的应用程序和数据库实例并保持它们同步时，会出现一些问题，因此您必须管理sql服务器之间的id池（例如：sql1使用100到200之间的id，sql2使用201到300之间的id）-这是薄冰。 对于guid id，您不关心id池

您对我的镜像应用程序（和db）有什么建议：使用传统ID还是使用GUI

---

提前感谢您的回复

我在涉及复制或客户端ID生成的任何场景中都使用GUID。在这两种情况下，使用GUID管理标识都会容易得多

对于两层场景，例如web应用程序直接与数据库通信，或者对于不需要复制（或者可能只需要在一个方向上复制，pub/sub样式）的服务器，我认为自动递增的ID列就可以了

---

至于是继续使用autoincs还是移动到GUI。。。在绿地应用程序中提倡使用guid是一回事，在这里您可以提前做出所有这些决定。建议某人迁移现有数据库是另一回事。这可能比它的价值更痛苦。

当发生页面拆分时，guid在性能和并发性方面存在问题。INTs可以以100%的速度运行页面填充，只在一端添加，Guid在任何地方添加，因此您可能必须运行较低的填充，这会浪费整个索引的空间

可以在应用程序中分配guid，这样应用程序就可以知道它将创建的记录的ID，这很方便；但是，从技术上讲，可以生成重复的GUID（可能性很大，但至少在GUID列上放置一个唯一的索引）

---

我同意合并数据库比较容易。但对我来说，直接整数更好，然后在实际需要的时候/如果需要的话，就要处理如何合并DBs的问题。

如果数据经常移动，那么GUID是表键的最佳选择。 如果您真的关心性能，只需使用int或bigint即可

如果您想利用以上两种方法，请使用int或bigint作为表的键，并且每行都可以有一个rowguid列，这样数据也可以在不丢失完整性的情况下轻松移动。

guid具有

优点：

• 能够从数据库脱机创建它们，而不必担心冲突
• 你永远不会用完它们的

缺点：

• 顺序插入的性能可能很差（尤其是在聚集索引上）。
  • 解决这个问题
• 每行占用更多空间
• 创建一个干净的是不便宜的
  • 但是如果客户机正在生成它们，这实际上是没有问题的

列仍应具有唯一性约束（作为PK或单独约束，如果它是其他关系的一部分），因为没有任何东西会阻止某人手动提供GUID并意外/故意违反唯一性

---

如果空间没有影响到你，如果你的表现没有受到显著影响，那么很多问题就会迎刃而解。这个决定不可避免地是针对应用程序的个人需求而做出的。

如果ID将显示在查询字符串中，请使用GUID，否则请使用long as规则。

我从来没有听说过顺序GUID，但应该可以-只需添加实例前缀/后缀。还有一个缺点。。。当您手动操作表中的数据时，无法记住GUID，必须剪切和粘贴GUID才能执行任何有价值的操作。您也不能使用>或fair point更新/删除数据集，强制复制/粘贴而不是从内存中复制/粘贴有时可以避免问题，但会降低某些操作的速度。如果您有一个用于测试的通用id，那么将其放在某个地方（可能作为一个函数，像GetTestFooId（）一样返回它）是值得的，因为Foo是有意义的。我不理解顺序GUI对自动递增长度的兴趣：基本原理是一样的：每个人都能够预测您的下一个id，这个想法让我感到不舒服。如果这是一个安全风险罚款，两者都不用。对于许多用户来说，这不是问题，因为该字段不用于外部消费。