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聚簇索引+合併複製+外鍵

回答

相關問題