GUID几乎总是会变慢,因为它们更大.这使您的索引更大.这使你的桌子更大.这意味着如果您必须全部或部分扫描您的表,则需要更长时间才能看到较少的性能.这是基于报告的系统的一个重大问题.例如,在事实表中永远不会使用GUID作为外键,因为它的长度通常是很重要的,因为事实表经常被部分扫描以生成聚合.

还要考虑使用“长”是否合适.这是一个非常大的数字.你只需要它,如果你认为你的表中有可能有超过2亿美元的条目.我很少使用它们.

GUID也可能很难使用和调试.说,“客户记录10034有一个问题,弗兰克,去看看”比说“容易得多”{2f1e4fc0-81fd-11da-9156-00036a0f876a}有一个问题…“Ints和longs也更容易在需要的时候输入查询.

呵呵,你不会再有两次GUID了.已知在非常大的断开连接的系统上发生,所以这是需要考虑的,虽然我不会在大多数应用程序中设计.

当GUID可以适当时

当您使用断开连接的系统(在实体被创建然后同步)时,GUID是适当的.例如,如果有人在您的数据库中记录移动设备并进行同步,或者您在不同的分支机构创建了实体,并在晚上同步到中央商店.这就是他们给你的灵活性.

在某些ORM方案中,GUID还允许您将实体关联而不将其持久存储到数据库. Linq to sql(我相信EF)没有这个问题,虽然有时你可能被迫将更改提交给数据库以获取密钥.

如果您在客户端上创建GUID,可能由于创建的GUID不是顺序的,因为DB上的页面分割,插入性能可能会受到影响.

我的建议

在这里考虑很多东西.我的投票是不要使用它们,除非你有一个令人信服的用例.如果表现真的是您的目标,请保持桌子小.保持你的田野很小.保持您的数据库索引小和选择性.