【发布时间】：2010-11-01 08:43:03
【问题描述】：
如果 uniqueidentifier 数据类型列是表 sql server 2005/2008 中的聚集/非聚集索引会有什么影响。我读到它是设计糟糕的表格，如何避免这个问题以及最好的解决方案是什么？
【问题讨论】：
标签： sql-server-2005 database-design
【发布时间】：2010-11-01 08:43:03
【问题描述】：
如果它是非集群的，它只是意味着索引将是宽的（每行 16 字节，而不是每行 4 字节的整数）。
如果它是集群的，那么插入将导致页面拆分，具体取决于您在创建/重建索引时在索引中留下多少可用空间（填充因子）。
关于SO讨论这个话题有几个问题：
Should I get rid of clustered indexes on Guid columns
Advantages and disadvantages of GUID / UUID database keys
Clustered primary key on unique identifier ID column in SQL Server
【讨论】：
GUID 对于 SQL Server 中的聚集索引来说是一个糟糕的选择，因为由于其值的随机性，聚集索引会严重碎片化。
此外，由于聚集索引字段被复制到每个非聚集索引中，它还可能导致 SQL Server 中磁盘和内存空间的大量浪费。
从程序员的角度来看，GUID 是一个很好的选择 - 或多或少是随机的，几乎可以保证是唯一的 - 但从数据库的角度来看，在 SQL Server 中将它们用作聚集索引是非常糟糕的选择。
请参阅 Kim Tripp 的各种文章 - 非常有趣！
http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx
http://sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-Continues.aspx
马克
【讨论】：
-
如果在 GUID 上的聚集索引中留有空间（即填充因子），它不一定像经常报告的那样糟糕。如果您有定期索引维护和经过深思熟虑的填充因子。话虽如此，我尽量不在 GUIDS 上创建聚集索引...
-
是的 - 您可以通过一些技巧来减轻影响 - 但作为集群键的 GUID 总是不如 INT 周期理想。此外，浪费的空间（乘以包含集群键的所有非集群索引）不能被优化掉.....