标识列作为主键
对于服务器端生成的密钥，在没有复制或大量数据合并的环境中，IDENTITY密钥是一种很好的做法。他们实施的方式，他们不允许在同一个表中重复，所以不要担心。它们还具有将不具有大量DELETE的表中的碎片最小化的优点。
GUID是通常的选择。他们的优势是您可以在Web层创建它们，而无需往返数据库。但是，它们比IDENTITIES大，并且会导致极端的表碎片。由于它们是（半）随机的，所以插入遍布整个表格，而不是集中在最后一页。
为了解决GUID的问题碎片，使用COMB风格的GUID而不是标准的完全随机的。在MSSQL上，有一种半COMB实现，有时“足够好”，但不能保证跨服务器重启时的页面插入。在大多数情况下，int或bigint与GUID（128位）之间的空间差异不值得担心。 – richardtallent 2009-12-03 07:54:34
除了在服务器重启之间不保持顺序（如果那么长），NEWSEQUENTIALID功能也不会阻止碎片或页面拆分;它只是将它本地化在一个区域，直到值重置。另外，NEWSEQUENTIALID只能用作列默认值，所以它只能在服务器上生成。此外，以这种方式生成的GUID比“纯”GUID更具可猜测性 - 因此，使用GUID超过IDENTITY的三个好处并不适用于NEWSEQUENTIALID。 – RickNZ 2009-12-03 09:18:13
我使用GUID，因为它在我处理的分布式应用程序确实有帮助。尤其是当所有分布式实例也需要创建新数据时。
不过，在简单的情况下，我看不到任何与自动增量整数主键有关的问题。我更喜欢它们，因为它更容易直接使用SQL查询，因为它更易于记忆。
是的，使用INT（或BIGINT）IDENTITY是SQL Server非常好的做法。
SQL Server使用主键作为其默认的聚集键和聚集键应该始终有这些属性：
- 窄
- 静态
- 独特
- 不断增加
INT IDENTITY完美适合您的账单！
欲了解更多的背景信息，尤其是一些信息，为什么一个GUID作为主（因此聚集键）是一个坏的想法，看到金佰利特里普的优秀帖子：
- GUIDs as PRIMARY KEYs and/or the clustering key
- The Clustered Index Debate Continues...
- Ever-increasing clustering key - the Clustered Index Debate..........again!
如果你有理由使用GUID作为主键（例如。复制），那么通过所有方法确保在这些表上有一个INT IDENTITY作为您的集群密钥！
Marc
与应用程序中生成的自然键或代理键（hi/lo，guid等）相反？ – 2009-12-03 07:11:00
请参阅http://*.com/questions/262547/reasons-not-to-use-an-auto-incrementing-number-for-a-primary-key，因为这可能是dup – Rippo 2009-12-03 07:21:02