我爱我的 GUID。但是，最近我一直在做一些研究以了解主键 IDENTITY 的实际优缺点，我发现 this article这很好地总结了它。
作者在文章中写道:
- highly useful for data warehousing;
作为使用 IDENTITY 而不是 GUID 的优点之一。
我会理解，对于特别大的数据库，就像数据仓库一样，大小确实很重要 - 但是似乎还有其他原因，文章未能解释。所以我问:
为什么 GUID 不适合日期仓储？
最佳答案
GUID 似乎是您的主键的自然选择 - 如果您真的必须这样做，您可能会争辩说将它用于表的 PRIMARY KEY。我强烈推荐的内容 不做使用 GUID 列作为 聚类 key ，默认情况下 SQL Server 会这样做，除非您明确告诉它不要这样做。
你真的需要把两个问题分开:
1) 主键 是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这可以是任何东西，实际上 - 一个 INT、一个 GUID、一个字符串 - 选择最适合您的场景的内容。
2) 聚类 key (定义表上“聚集索引”的一列或多列)——这是一个与物理存储相关的东西，在这里，一个小的、稳定的、不断增加的数据类型是你最好的选择——INT 或 BIGINT 作为你的默认值选项。
默认情况下，SQL Server 表上的主键也用作集群键 - 但不必如此!当将之前的基于 GUID 的主键/集群键分解为两个单独的键时，我个人看到了巨大的性能提升 - GUID 上的主(逻辑)键和单独的 INT IDENTITY(1,1) 上的集群(排序)键柱子。
如 Kimberly Tripp - 索引女王 - 和其他人已经说过很多次了 - GUID由于集群键不是最优的，由于其随机性，它会导致大量的页面和索引碎片，并且通常会导致性能不佳。
是的，我知道 - 有 newsequentialid()在 SQL Server 2005 及更高版本中 - 但即使这样也不是真正和完全顺序的，因此也会遇到与 GUID 相同的问题。 - 只是不那么突出。
那么还有一个问题需要考虑:表上的集群键将被添加到 每个非聚集索引上的每个条目 在你的 table 上 - 因此你真的想确保它尽可能小。通常，对于绝大多数表来说，具有 2+ 十亿行的 INT 应该足够了 - 与作为集群键的 GUID 相比，您可以在磁盘和服务器内存上节省数百兆字节的存储空间。
快速计算 - 使用 INT 与 GUID 作为主键和集群键:
总计:25 MB 与 106 MB - 那只是在一张 table 上!
还有一些值得深思的东西——金伯利·特里普 (Kimberly Tripp) 的优秀作品——阅读它，再读一遍，消化它!这是 SQL Server 索引的福音，真的。
马克
关于sql - 为什么 IDENTITY 优于 GUID 作为数据仓库的主键？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11033435/