如何擺脫作爲主鍵的guid字段

我陷入了一片混亂，並期待看看我能否擺脫困境。我有一個數據庫，其中包含uniqueidentifier列上定義的表上的所有主鍵。這是對我們的強迫，給予'安全'作爲其中一個原因。另一個我認爲比較有價值的理由是有些表參與複製。如何擺脫作爲主鍵的guid字段

我在審查數據庫，我覺得一個容易避免的未來性能瓶頸是可以在所有表中添加自動增量bigint列並使其成爲主鍵（集羣）。並以某種方式正確地「附加」pk-fk關係。但仍然保留舊的列以備將來使用。

在這方面的任何建議/意見/ donots？我們是一個C＃/ MSSQL服務器R2/Linq環境。

編輯： 看看評論，我意識到我遺漏了一些重要的細節。所有的主鍵Guid字段都是集羣的，並且我沒有使用newsequentialId（我們使用Linq to SQL，主鍵是生成客戶端的，在涉及複製的情況下，我們不確定如何從不同的客戶端環境正確生成順序標識符沒有衝突）。

我的'感覺'是由於已知的事實，即guid列上的聚集索引將導致高度的碎片化並且只會隨着數據庫的增長而惡化情況。另外，我現在不是真的在嘗試優化，而是試圖糾正一個糟糕的設計，以避免數據庫變得太大時將來的頭痛。想知道現在是否值得去做。

有益的討論也與這裏的問題this post，並且 another

來源

2013-08-28 Brian

'我覺得一個容易避免性能瓶頸是可以添加自動遞增bigint'，有點意見。不要優化感覺。 –

基準您的數據庫。用'BIGINT'將數據複製到另一個表中，看看性能損失是否真的是一個問題。 – Romoku

p.s.這可能是更好的http://dba.stackexchange.com/ –

性能調優數據庫其實很簡單，但很難。首先，您需要通過在至少一個工作日內運行長時間運行的配置文件來收集針對數據庫執行的語句列表，但最好是兩個。

將該配置文件保存到數據庫以便查詢，因此您可以輕鬆找到DISTINCT針對您的數據庫執行的查詢。

確定執行最多的人後，分析他們的執行計劃，很可能有什麼做的GUID的和一切有任何查詢自己做（即他們太可怕了）或你需要一個不同的索引。

事情需要提防：

查看被大量用WHERE條款過濾。這些對於存儲過程或參數化視圖來說都是非常棒的候選。
JOIN到非常大的表格，那些時間可以是子查詢的好候選物。這取決於執行計劃。
出現要多次執行的語句。這通常是一個好兆頭，即應用程序本身在管理服務器往返次數方面做得並不好。我見過的應用程序將運行相同的查詢10次以上。

來源

2013-08-28 13:19:46

謝謝。這非常有幫助。我將在性能調整時將這些步驟添加到我的待辦事項列表中。順便說一句，我沒有收到你對LievenKeersmaekers的評論？ – Brian

@Brian，閱讀Eric Lippert關於GUID的整個系列，http：//blogs.msdn.com/b/ericlippert/archive/tags/guids/，該數字讓我們知道GUID是順序的還是隨機的。大多數GUID都是基於MAC地址的，因此它們實際上是連續的 - 但這是一個常見的誤解。 –

一個權宜之計可以使用NEWSEQUENTIALID（）而不是NEWID（）。至少通過這種方式，你不會得到儘可能多的碎片。

創建一個GUID，該GUID比自從Windows啓動以來在指定的計算機上由此函數以前生成的任何GUID大。重新啓動Windows後，GUID可以從一個較低的範圍內重新開始，但仍然是全球唯一的。當GUID列用作行標識符，使用NEWSEQUENTIALID可以比使用NEWID 函數更快。這是因爲NEWID函數會導致隨機活動並使用較少的緩存數據頁面。使用NEWSEQUENTIALID還有助於完全填充數據和索引頁面。

http://technet.microsoft.com/en-us/library/ms189786.aspx

注意，這並不一定會幫助取決於他們是什麼您解決性能問題的（也許你能否詳細說明 - 插入SELECT過濾等？）。

來源

2013-08-28 13:41:36

我同意。我的評論（在原始問題中）有一個「客戶端順序uuid」解決方案，以配合這個建議。 – granadaCoder

@MarkSowul問題已更新 – Brian

看一看金佰利特里普的建議在http://www.sqlskills.com/blogs/kimberly/disk-space-is-cheap/

她建議以下步驟轉換到非GUID聚集關鍵字：

如果CL關鍵是PK那麼這裏是你的步驟：

Take the database offline (sorry, I’m just the messenger!!) 
Disable the FKs 
Disable the nonclustered indexes 
Drop the clustered PK (alter table) 
Optionally, add an identity column? 
Create the new clustered index 
Create the PK as nonclustered 
Enable the nonclustered indexes (alter index…rebuild) 
Enable the FKs with CHECK (this is very important) 
Bring the database online

來源

2013-08-30 04:09:10

如何擺脫作爲主鍵的guid字段

回答

相關問題