我有一个包含大量行（10K +）的表，主键是GUID。主键是群集的。此表的查询性能非常低。请提供建议以提高效率。
答案 0 :(得分：39)
GUID上的聚簇索引不是一个好设计。 GUID的本质是它是随机的，而聚簇索引通过密钥对记录进行物理排序。这两件事完全不一致。对于每个插入SQL，必须重新排序磁盘上的记录！从此索引中删除聚类！
使用群集的时间是指您对数据有“自然”顺序：插入时间，帐号等。对于时间字段，群集几乎是免费的。对于帐号，它可能是免费的或便宜的（当按顺序分配帐号时）。
尽管可能存在围绕GUID问题的技术方法，但最好的想法是了解何时使用群集。
答案 1 :(得分：7)
使用GUID作为主键没有问题。只需确保在实际将GUID设置为主键时，将其自动创建的索引设置为非群集类型。许多人忘记（或不知道）在SQL Server中执行此操作。
永远不要在GUID上使用聚簇索引。这将导致磁盘上GUID周围的物理排序，这显然毫无意义（正如其他人已经指出的那样）
答案 2 :(得分：5)
您需要使用newsequentialid（）而不是请参阅此处Some Simple Code To Show The Difference Between Newid And Newsequentialid
答案 3 :(得分：2)
您可以尝试顺序GUIDS，这将使索引更有效。信息here。
答案 4 :(得分：1)
您需要分析您的查询。我们只能猜测为什么你的查询在没有查看执行计划的情况下表现不佳（你可以从SQL Server或Oracle轻松获得安静）。
考虑到GUID是128位值（如果存储为raw），GUID会将数据和索引块的密度降低50％（在主键索引的情况下），因此请确保GUID是合适的。
但这可能不是问题，因此请查看查询计划。这可能是其他几个问题。
答案 5 :(得分：-5)
请避免为lenghty字符串列创建聚簇索引。 GUID将有36个字符。即使您已创建为聚簇索引，它也会降低查询性能。为了更好的练习，请使用整数标识列。