GUID PK + INT IDENTITY聚簇索引+合并复制+外键

我有一个带有GUID PK的数据库，并且我理解添加INT IDENTITY列（例如ClusterID），然后在其上创建聚簇索引会带来的性能优势。GUID PK + INT IDENTITY聚簇索引+合并复制+外键

而对于连接，使用ClusterID列作为外键会带来性能上的好处。特别是在父/子情况下，子表可以在父母ClusterID上有聚集索引。

但是在合并复制的情况下，这是不可能的，因为ClusterID列不一定是唯一的。

所以我想知道在这种情况下如何最好地获得性能优势。

例如：

表A

ID GUID（主键）
丛集编号INT标识（聚簇索引）`

表B

ID GUID （主键）
TableAID GUID（外键表A）
TableAClusterID INT（聚集索引）`

我想我会使用触发器来保持TableAClusterID跟上时代的。

然后查询如

select * 
from TableB B 
where B.TableAClusterID = @TableAClusterId

将受益于更高的性能。

这是如何完成的？

来源

2015-04-23 Dale Burrell

你在说什么性能好处？插入性能？不成？ – Ben

为什么ClusterID在合并复制方案中不是唯一的？如果您使用自动身份范围管理，那么保证ID将是唯一的。 –

@Ben - 虽然http://www.sqlskills.com/blogs/kimberly/the-clustered-index-debate-continues/接近，但我从所阅读的内容中找不到一篇文章总结了它即使列中没有使用数据，性能通常也会随着聚集索引而提高。 –

对于非常沉重的INSERTS GUID，其执行效率会高于INT IDENTITY，因为您不会争用它。有一些技术来解决它，但它仍然可能是一个问题。在所有其他情况下，INT/BIGINT表现更好。它们在非常大的范围内是独一无二的，尺寸比GUID小2-4。如果您将这些额外的12个字节乘以使用GUID的行数，然后乘以集群GUID索引上构建的非聚集索引的数量，则会看到该垃圾使用的数据库大小的%%。我认为，如果不是更多，你的表现也会有同样的下降。大小总是很重要。

来源

2016-06-18 19:20:02

GUID PK + INT IDENTITY聚簇索引+合并复制+外键

回答

相关问题