SQL主键

GUID似乎是您主键的自然选择 - 如果您真的必须，您可能会争辩将其用于表的PRIMARY KEY。我强烈建议不要使用GUID列作为群集密钥，默认情况下SQL Server会执行此操作，除非您明确告知不要这样做。 你真的需要分开两个问题： 1）主键是一个逻辑结构 - 一个候选键，它唯一且可靠地标识表中的每一行。这可以是任何东西，真的 - 一个INT，一个GUID，一个字符串 - 选择对你的场景最有意义的东西。 2）聚类键（在表上定义“聚簇索引”的一列或多列） - 这是一个与物理存储相关的东西，这里，一个小的，稳定的，不断增加的数据类型是你最好的选择 - INT或BIGINT作为默认选项。 默认情况下，SQL Server表上的主键也用作群集键 - 但这不一定是这样！我个人看到将以前基于GUID的主/群集密钥分解为两个单独的密钥 - GUID上的主（逻辑）密钥和单独的INT IDENTITY上的群集（排序）密钥（1， 1）专栏。 正如Kimberly Tripp--索引女王 - 和其他人已多次声明 - GUID因为聚类键不是最佳的，因为由于其随机性，它将导致大量页面和索引碎片以及通常不良的性能。 是的，我知道 - 在SQL Server 2005及更高版本中有

newsequentialid()

- 但即使这样也不是真正的，完全顺序的，因此也会遇到与GUID相同的问题 - 只是不那么突出。如果你坚持GUID，那么至少在服务器上使用

newsequentialid()

方法！ 然后还有另一个需要考虑的问题：表格上的聚类键也会添加到表格中每个非聚集索引的每个条目上 - 因此您确实希望确保它尽可能小。通常，对于绝大多数表来说，具有2亿行的INT应该足够 - 并且与作为群集密钥的GUID相比，您可以在磁盘和服务器内存中节省数百兆的存储空间。 快速计算 - 使用INT与GUID作为主要和群集密钥： 基表有1'000'000行（3.8 MB对15.26 MB） 6个非聚簇索引（22.89 MB对91.55 MB） 总计：25 MB对106 MB - 这只是在一张桌子上！ 还有一些值得深思的东西 - 金佰利特里普的优秀作品 - 阅读，再读一遍，消化它！这是SQL Server索引福音，真的。 GUID为PRIMARY KEY和/或群集密钥 聚集指数的争论仍在继续 不断增加的聚类密钥 - 聚集索引辩论..........再次！ 磁盘空间很便宜 - 这不是重点！ 渣     

当我有这样的问题时，我对自己说“SQL Server擅长集合，所以让它让它做得好”，有时“1只是N的特定情况”。   哪种方法更适合单身   插入？ 对于同步sql调用的任何一种方法，单个插入时间都是相同的。然而，“他的”方法会给你带来更多问题，因为他的顺序guid方法不会像sql服务器一样好（你可能会失去全局唯一性）。当您不可避免地需要进行多次插入时，它还会拆分您的代码库。   哪种方法更适合多种方法   在事务中插入？ 如果您正在争论基于集合的插入（插入/选择）v.s.单行插入（插入），基于集合将在多个插入上获胜，因为回到客户端的行程是昂贵的部分。 如果这是我，我将创建一个SP，其中包含要插入的对象的序列化集合，使用输出子句执行insert / select，在此页面上查看“示例B.使用带有标识和计算列的OUTPUT”，让sql server创建GUID（如果你被卡在上面）并返回到客户端或运行SP中的下一个语句，根据insert生成的输出表插入子行。