SQL server中的GUID列排序與Cluster Index

今天在項目中調查一個defect，發現SQL server對GUID列排序與Cluster Index的特殊處理。這裡涉及到兩個知識點，一是SQL server 對GUID列的排序演算法實現，二是Cluster Index和NonCluster Index的區別。先說一下SQL Server對GUID列的排序是如何?的。具體文章在這： 

http://blogs.msdn.com/b/sqlprogrammability/archive/2006/11/06/how-are-guids-compared-in-sql-server-2005.aspx

簡要的演算法就是，GUID 格式是 {000000000-0000-0000-00000000}，比較是以位元組為單位來比較的。先從10-15位開始比，然後是8-9位，6-7位，4-5位，0-3位這樣的方式來做的。因此要特別注意這種方法與.net裡面的方法是不同的。再來說Cluster index與NonCluster Index的區別。第一個主要的區別是儲存的方式不同，Cluster Index被建立後的行記錄的儲存是以物理位置優先為原則的。也就是說SQL server會儘可能的在同一個儲存頁，在相鄰的位置去儲存行記錄資訊（用的是追加的方式）。這樣的話記錄儲存的非常連續，資料庫在尋找和讀取的時候就會很快，因為不用在儲存頁間跳轉。但是同時也帶來一個問題就是為了保證行記錄的連續性，在插入和更新行記錄的時候需要移動其他記錄的位置，這會導致插入的時候效能問題。而NonCluster Index的好處正在於此，它是邏輯儲存的，索引資訊記錄了行記錄在那個儲存頁和頁內位移，所有的索引資訊以樹的形式儲存。這樣對於插入資料來說是很容易的，只要能找到空閑頁，記錄頁號與位移即可。同時對於查詢和讀取來說，在樹上定位索引再到指定的頁面讀取記錄會相對的慢一些，因此如何設定表的索引需要三思而行。而這裡我要說的問題是，當GUID列被作為Cluster Index時無論GUID值是否發生改變，只要進行了Update操作，它的行序號就會發生改變。也就是說使用同樣的select語句對相同的記錄進行查詢會得到不同的記錄順序。所以這個是在使用Cluster Index時要注意的問題。