我有一个包含大量行（10K+）的表，它的主键是 GUID。主键是集群的。此表的查询性能相当低。请提供建议以使其高效。
trailblazer
问问题
16135 次
6 回答
42
GUID 上的聚集索引不是一个好的设计。GUID 的本质是它是随机的，而聚集索引通过键对记录进行物理排序。这两件事完全不一致。对于每个插入 SQL 都必须重新排序磁盘上的记录！从此索引中删除集群！
使用聚类的时间是当您对数据具有“自然”顺序时：插入时间、帐号等。对于时间字段，聚类几乎是免费的。对于帐号，它可能是免费的或便宜的（当帐号按顺序分配时）。
虽然可能有解决 GUID 问题的技术方法，但最好的办法是了解何时使用集群。
于 2009-02-24T18:46:58.490 回答
7
使用 GUID 作为主键没有问题。只需确保当您实际将 GUID 设置为主键时，然后将它自动创建的索引设置为非聚集类型。很多人忘记（或不知道）在 SQL Server 中执行此操作。
切勿在 GUID 上使用聚集索引。这将导致围绕磁盘上的 GUID 进行物理排序，这显然是没有意义的（正如其他人已经指出的那样）
于 2010-04-22T11:08:10.363 回答
5
您需要使用 newsequentialid() 代替在这里查看一些简单的代码来显示 Newid 和 Newsequentialid 之间的区别
于 2009-02-24T18:48:15.663 回答
2
您可以尝试顺序 GUIDS，这将使索引更有效。信息在这里。
于 2009-02-24T18:43:34.877 回答
1
您需要分析您的查询。我们只能在不查看执行计划的情况下猜测为什么您的查询执行不佳（您可以从 SQL Server 或 Oracle 轻松获得安静）。
考虑到 GUID 是 128 位值（如果存储为原始值），GUID 将数据和索引块的密度降低了 50%（在主键索引的情况下），因此请确保 GUID 是合适的。
但这可能不是问题，因此请查看查询计划。可能是其他几个问题。
于 2010-03-10T16:01:31.347 回答
-5
请避免为长字符串列创建聚集索引。GUID 将有 36 个字符。即使您创建为聚集索引，它也会降低查询性能。为了更好地实践，请使用整数标识列。
于 2009-12-02T10:35:46.803 回答