我有问题，我们应该在表中使用Int/GUID。使用这种情况。SQL SERVER - INT Vs GUID - 我们应该使用
使用BIGINT作为主键 - 聚集等，用于连接，快速检索等，即为检索和用户便利而优化。
将GUID作为您记录的唯一标记，这是您在跨服务器/应用程序移植数据时所使用的内容。这绝不会显示给用户，而是记录到所有记录。
这为您提供了两全其美的解决方案，避免了使用GUIDs作为主键的碎片和性能问题，但在移动数据/在系统之间共享数据时保留其优势，因为您可以独立识别记录。
有些人可能会争辩说额外的存储成本过高，但我认为从长远来看，在SAN上花费几美元更便宜，而不是试图用同一数据列做两件不同的事情。
我个人使用INT IDENTITY为我的大多数主要和集群密钥。
您需要分开主键这是一个逻辑构造 - 它唯一标识您的行，它必须是唯一和稳定的，并且NOT NULL。 A GUID也适用于主键 - 因为它保证是唯一的。 A GUID作为主键是一个很好的选择，因为在这种情况下，无论如何，您都需要一个唯一标识的列GUID。
集群密钥在SQL Server中是一种物理结构，用于数据的物理排序，而且要正确得多。通常，SQL Server上的索引女王Kimberly Tripp也需要一个良好的集群密钥，以保持独特稳定，尽可能的窄，并且理想情况下不断增加（这是一个INT IDENTITY）。
看到她文章的索引位置：
，也看到吉米·尼尔森的The Cost of GUIDs as Primary Key
对于聚簇密钥，GUID是一个非常糟糕的选择，因为它很宽，完全是随机的，因此会导致索引碎片不良和性能不佳。此外，集群密钥行也存储在每个非聚集索引的每个条目中，因此您确实希望将它保持较小 - GUID为16字节，INT为4字节，并且有几个非聚集索引和几百万行，这会产生巨大的差异。
在SQL Server中，您的主键默认情况下是您的集群密钥 - 但并非必须如此。您可以轻松使用GUID作为您的非群集主键，并将INT IDENTITY用作您的群集键 - 它只需要一点点知道它。