使用字符數據代表GUID主鍵的反模式有多常見？

Question

我最近在考慮將GUID作爲主鍵，並提醒我們曾經遇到過最嚴重的錯誤使用：

該數據庫包含很多Entity-Detail父子關係，如Receipt，它具有了LineItem。大多數細節表（本例中爲LineItem）使用GUID主鍵。但不是使用MSSQL的uniqueidentifier類型進行存儲，而是以'{00000000-0000-0000-0000-000000000000}'的形式存儲爲38個字符的字符串。哦，他們幾乎總是在nvarchar（Unicode）列中，每個字節以76字節爲單位（而不是唯一標識符的16字節）。

這些字段多久加入一次？幾乎在系統中的每一個查詢。數百個客戶端數據庫，數百萬條記錄適合這個配置文件。壞。

在引入uniqueidentifier時，系統在我的記憶中並沒有在SQL Server 7.0之前。這只是導致這個問題的知識/研究的徹底失敗。

我有兩個問題：

• 如何常見的，在你的經驗，這是反模式？

• 似乎很明顯76字節的Unicode字符串上的連接會比16字節的二進制數字上的連接速度慢很多，帶有索引或不帶。但任何人都可以提供一個想法，這可能會帶來什麼性能？假定您在兩種情況下編入連接列。

Answer 1

我認爲這個問題是沒有這麼多加盟的76個字節鍵和16個字節的密鑰，但更多的內在速度差：

多少行可以包到每個8K頁面（即獲得更多頁面拆分/更多碎片化索引/更糟糕的性能）....

另外 - 你沒有提到，如果這些僞裝的GUID是連續的或不。如果他們是主鍵的一部分，關鍵是聚集然後每次插入可能潛在重組表的完整B樹........

而且任何非聚集索引你對錶包含主鍵（因此他們可以對查詢進行查找，而不是非聚集索引100％滿意）。所以你的非聚簇索引要比在UNIQUEIDENTIFIER類型的表上大很多。

我還沒有看到GUID的建模爲在任何公司我工作過的字符串，但我有在哪裏見過的PK是聚集和GUID被選爲沒有特別的理由了幾桌。適用於小數據集，然後.....生產中的性能問題。