簡述sqlserver數據庫主鍵選取策略

因爲主鍵可以唯一標識某一行記錄，所以可以確保執行數據更新、刪除的時候不會出現張冠李戴的錯誤。當然，其它字段可以輔助我們在執行這些操作時消除共享衝突，不過就不在這裏討論了。主鍵除了上述作用外，常常與外鍵構成參照完整性約束，防止出現數據不一致。所以數據庫在設計時，主鍵起到了很重要的作用。

常見的數據庫主鍵選取方式有：

自動增長字段

手動增長字段

UniqueIdentifier

“COMB（Combine）”類型

一、自動增長型字段

很多數據庫設計者喜歡使用自動增長型字段，因爲它使用簡單。自動增長型字段允許我們在向數據庫添加數據時，不考慮主鍵的取值，記錄插入後，數據庫系統會自動爲其分配一個值，確保絕對不會出現重複。如果使用SQL Server數據庫的話，我們還可以在記錄插入後使用@@IDENTITY全局變量獲取系統分配的主鍵鍵值。

儘管自動增長型字段會省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在數據緩衝模式下，很難預先填寫主鍵與外鍵的值。假設有兩張表：

Order(OrderID, OrderDate)

OrderDetial(OrderID, LineNum, ProductID, Price)

Order表中的OrderID是自動增長型的字段。現在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因爲Order表中的OrderID是自動增長型的字段，那麼我們在記錄正式插入到數據庫之前無法事先得知它的取值，只有在更新後才能知道數據庫爲它分配的是什麼值。這會造成以下矛盾發生：

首先，爲了能在OrderDetail的OrderID字段中添入正確的值，必須先更新Order表以獲取到系統爲其分配的OrderID值，然後再用這個OrderID填充OrderDetail表。最後更新OderDetail表。但是，爲了確保數據的一致性，Order與 OrderDetail在更新時必須在事務保護下同時進行，即確保兩表同時更行成功。顯然它們是相互矛盾的。（此處表述有錯誤。呂震宇 2005-6-15）

【補充2005-6-15】---------------------------------------------

聽棠指出：主檔放在事務中提交時，通過@@IDENTITY 就可以取到生成值的，因此可以傳給明細當外鍵用，而且在事務發生錯誤回滾時，主檔記錄也會被回滾取消的。

呂震宇補充：使用自動增長字段會增加網絡的roundTrip。儘管可以使用@@IDENTITY取得主鍵的值，但在更新過程中，不得不增加一次數據往返（以C/S結構爲例）：

1、客戶端發送開始事務命令

2、客戶端提交主表更新

3、服務器返回@@IDENTITY

4、客戶端根據返回的主鍵更新從表緩衝

5、客戶端將從表提交服務器更新

6、客戶端提交事務

在這裏多了一次往返就會增加了事務處理的時間。降低併發性能。

如果不用自動增長型字段，將是以下情景：

1、客戶端發送開始事務命令

2、客戶端提交主表更新

3、客戶端提交從表更新

4、客戶端提交事務

因此我不贊成使用自動增長型字段作爲主鍵與外鍵鏈接的紐帶。

------------------------------------------------

除此之外，當我們需要在多個數據庫間進行數據的'複製時（SQL Server的數據分發、訂閱機制允許我們進行庫間的數據複製操作），自動增長型字段可能造成數據合併時的主鍵衝突。設想一個數據庫中的Order表向另一個庫中的Order表複製數據庫時，OrderID到底該不該自動增長呢？

允許我們在DataSet中將某一個字段設置爲自動增長型字段，但千萬記住，這個自動增長字段僅僅是個佔位符而已，當數據庫進行更新時，數據庫生成的值會自動取代分配的值。所以爲了防止用戶產生誤解，建議大家將中的自動增長初始值以及增量都設置成-1。此外，在中，我們可以爲兩張表建立DataRelation，這樣存在級聯關係的兩張表更新時，一張表更新後另外一張表對應鍵的值也會自動發生變化，這會大大減少了我們對存在級聯關係的兩表間更新時自動增長型字段帶來的麻煩。

二、手動增長型字段

既然自動增長型字段會帶來如此的麻煩，我們不妨考慮使用手動增長型的字段，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表存儲當前主鍵鍵值。還用上面的例子來說，這次我們新建一張表叫IntKey，包含兩個字段，KeyName以及KeyValue。就像一個HashTable，給一個KeyName，就可以知道目前的KeyValue是什麼，然後手工實現鍵值數據遞增。在SQL Server中可以編寫這樣一個存儲過程，讓取鍵值的過程自動進行。代碼如下：

複製代碼 代碼如下:

CREATE PROCEDURE [GetKey]

@KeyName 10),

@KeyValue int OUTPUT

AS

UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + 1 WHERE KeyName = @KeyName

GO

這樣，通過調用存儲過程，我們可以獲得最新鍵值，確保不會出現重複。若將OrderID字段設置爲手動增長型字段，我們的程序可以由以下幾步來實現：首先調用存儲過程，獲得一個OrderID，然後使用這個OrderID填充Order表與OrderDetail表，最後在事務保護下對兩表進行更新。

使用手動增長型字段作爲主鍵在進行數據庫間數據複製時，可以確保數據合併過程中不會出現鍵值衝突，只要我們爲不同的數據庫分配不同的主鍵取值段就行了。但是，使用手動增長型字段會增加網絡的RoundTrip，我們必須通過增加一次數據庫訪問來獲取當前主鍵鍵值，這會增加網絡和數據庫的負載，當處於一個低速或斷開的網絡環境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮併發衝突等種種因素，這更會增加系統的複雜程度。

三、使用UniqueIdentifier

SQL Server爲我們提供了UniqueIdentifier數據類型，並提供了一個生成函數NEWID( )，使用NEWID( )可以生成一個唯一的UniqueIdentifier。UniqueIdentifier在數據庫中佔用16個字節，出現重複的概率非常小，以至於可以認爲是0。我們經常從註冊表中看到類似

{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}

的東西實際上就是一個UniqueIdentifier，Windows用它來做COM組件以及接口的標識，防止出現重複。在裏管 UniqueIdentifier稱之爲GUID（Global Unique Identifier）。在C#中可以使用如下命令生成一個GUID：

Guid u = uid();

對於上面提到的Order與OrderDetail的程序，如果選用UniqueIdentifier作爲主鍵的話，我們完全可以避免上面提到的增加網絡RoundTrip的問題。通過程序直接生成GUID填充主鍵，不用考慮是否會出現重複。

UniqueIdentifier字段也存在嚴重的缺陷：首先，它的長度是16字節，是整數的4倍長，會佔用大量存儲空間。更爲嚴重的是，UniqueIdentifier的生成毫無規律可言，要想在上面建立索引（絕大多數數據庫在主鍵上都有索引）是一個非常耗時的操作。有人做過實驗，插入同樣的數據量，使用UniqueIdentifier型數據做主鍵要比使用Integer型數據慢，所以，出於效率考慮，儘可能避免使用 UniqueIdentifier型數據庫作爲主鍵鍵值。

四、使用“COMB（Combine）”類型

既然上面三種主鍵類型選取策略都存在各自的缺點，那麼到底有沒有好的辦法加以解決呢？答案是肯定的。通過使用COMB類型（數據庫中沒有COMB類型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設計出來的），可以在三者之間找到一個很好的平衡點。

COMB數據類型的基本設計思路是這樣的：既然UniqueIdentifier數據因毫無規律可言造成索引效率低下，影響了系統的性能，那麼我們能不能通過組合的方式，保留UniqueIdentifier的前10個字節，用後6個字節表示GUID生成的時間（DateTime），這樣我們將時間信息與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。也許有人會擔心UniqueIdentifier減少到10字節會造成數據出現重複，其實不用擔心，後6字節的時間精度可以達到1/300秒，兩個COMB類型數據完全相同的可能性是在這1/300秒內生成的兩個GUID前10個字節完全相同，這幾乎是不可能的！在SQL Server中用SQL命令將這一思路實現出來便是：

複製代碼 代碼如下:

DECLARE @aGuid UNIQUEIDENTIFIER

SET @aGuid = CAST(CAST(NEWID() AS BINARY(10))

+ CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)

經過測試，使用COMB做主鍵比使用INT做主鍵，在檢索、插入、更新、刪除等操作上仍然顯慢，但比Unidentifier類型要快上一些。關於測試數據可以參考我2004年7月21日的隨筆。

除了使用存儲過程實現COMB數據外，我們也可以使用C#生成COMB數據，這樣所有主鍵生成工作可以在客戶端完成。C#代碼如下：

複製代碼 代碼如下:

//================================================================

///

/// 返回 GUID 用於數據庫操作，特定的時間代碼可以提高檢索效率

///

///COMB (GUID 與時間混合型) 類型 GUID 數據

public static Guid NewComb()

{

byte[] guidArray = uid()teArray();

DateTime baseDate = new DateTime(1900,1,1);

DateTime now = ;

// Get the days and milliseconds which will be used to build the byte string

TimeSpan days = new TimeSpan(s - s);

TimeSpan msecs = new TimeSpan(s - (new DateTime(, h, )s));

// Convert to a byte array

// Note that SQL Server is accurate to 1/300th of a millisecond so we divide by 3.333333

byte[] daysArray = ytes();

byte[] msecsArray = ytes((long)(lMilliseconds/3.333333));

// Reverse the bytes to match SQL Servers ordering

rse(daysArray);

rse(msecsArray);

// Copy the bytes into the guid

(daysArray, th - 2, guidArray, th - 6, 2);

(msecsArray, th - 4, guidArray, th - 4, 4);

return new (guidArray);

}

//================================================================

///

/// 從 SQL SERVER 返回的 GUID 中生成時間信息

///

///包含時間信息的 COMB

///時間

public static DateTime GetDateFromComb( guid)

{

DateTime baseDate = new DateTime(1900,1,1);

byte[] daysArray = new byte[4];

byte[] msecsArray = new byte[4];

byte[] guidArray = teArray();

// Copy the date parts of the guid to the respective byte arrays.

(guidArray, th - 6, daysArray, 2, 2);

(guidArray, th - 4, msecsArray, 0, 4);

// Reverse the arrays to put them into the appropriate order

rse(daysArray);

rse(msecsArray);

// Convert the bytes to ints

int days = t32(daysArray, 0);

int msecs = t32(msecsArray, 0);

DateTime date = ays(days);

date = illiseconds(msecs * 3.333333);

return date;

}

結語

數據庫主鍵在數據庫中佔有重要地位。主鍵的選取策略決定了系統是否高效、易用。本文比較了四種主鍵選取策略的優缺點，並提供了相應的代碼解決方案，希望對大家有所幫助。