文章選自：《Pro SQL Server Internals, 2nd edition》CHAPTER 7 Designing and Tuning the Indexes中的Clustered Index Design Considerations一節

作者：Dmitri Korotkevitch

Clustered Index Design Considerations

聚集索引設計注意事項

       每次更改叢集索引鍵的值時，都會發生兩件事。首先，SQL Server移動行到群集索引頁鏈和資料檔案中的另一個位置。其次，它更新行id，這是群集索引鍵。行id儲存在所有非叢集索引中就需要更新。就I/O而言，這可能很昂貴，尤其是在批量更新的情況下。此外，它可以增加叢集索引的碎片化，以及在行id大小增加的情況下，非叢集索引的碎片化。因此,在鍵值不變的情況下，最好使用靜態聚集索引。

       所有非聚集索引都使用聚集索引鍵作為行編號。一個太寬的聚集索引鍵增加非聚集索引行的大小，並需要更多空間來儲存它們。因此，SQL Server在索引或範圍掃描操作期間需要處理更多的資料頁，這使得索引更少非常高效。

       對於非惟一非聚集索引，行編號也儲存在非葉索引級別，反過來，也減少了每頁索引記錄的數量，並可能導致索引中額外的中間級別。儘管非葉索引級別通常快取在記憶體中，但每次SQL Server遍歷非聚簇索引B-Tree時，這都會引入額外的邏輯讀取。

       最後，較大的非叢集索引會在緩衝池中使用更多空間，並在索引維護中帶來更多開銷。顯然，不可能提供一個通用閾值來定義可應用於任何表的鍵的最大可接受大小。但是，一般來說，最好是有一個窄的聚集索引鍵，索引鍵越小越好。

       將聚集索引定義為惟一的也是有益的。這很重要的原因不是顯而易見的。考慮一個場景，其中一個表沒有惟一的聚集索引，希望執行一個在執行計劃中使用非叢集索引的查詢。在這種情況下，如果行id是非集的索引不是唯一的，SQL Server不知道在鍵期間選擇哪個聚簇索引行查詢操作。

       SQL Server通過向非唯一聚簇索引中新增另一個名為uniquifier的可空整數列的操作來解決此類問題。對於第一次出現的鍵值，SQL Server用NULL填充uniquifiers，並對插入到表中的後續重複值進行自動遞增操作

■注意：每個聚簇索引鍵值的可能重複項數量受整數域值的限制。使用相同的聚集索引鍵的行不能超過2,147,483,648。 這是理論上的限制，建立一個選擇性這麼差的索引顯然是個不好的方式。

       讓我們看看在非惟一聚集索引中uniquifiers引入的開銷。所示的程式碼在圖7-1中，建立了三個相同結構的不同表，並使用65,536行填充它們。表dbo.UniqueCI定義了惟一叢集索引。表dbo.NonUniqueCINoDups沒有任何重複的鍵值。最後，表dbo.NonUniqueCDups在索引中有大量重複項。

圖7 – 1 非惟一聚集索引:表建立

create table dbo.UniqueCI

(

    KeyValue int not null,

    ID int not null,

    Data char(986) null,

    VarData varchar(32) not null

    constraint DEF_UniqueCI_VarData

    default 'Data'

);

create unique clustered index IDX_UniqueCI_KeyValue

on dbo.UniqueCI(KeyValue);

create table dbo.NonUniqueCINoDups

(

    KeyValue int not null,

    ID int not null,

Data char(986) null,

    VarData varchar(32) not null

      constraint DEF_NonUniqueCINoDups_VarData

      default 'Data'

);

create /*unique*/ clustered index IDX_NonUniqueCINoDups_KeyValue

on dbo.NonUniqueCINoDups(KeyValue);

create table dbo.NonUniqueCIDups

(

 KeyValue int not null,

     ID int not null,

 Data char(986) null,

     VarData varchar(32) not null

        constraint DEF_NonUniqueCIDups_VarData

        default 'Data'

);

create /*unique*/ clustered index IDX_NonUniqueCIDups_KeyValue

on dbo.NonUniqueCIDups(KeyValue);

-- Populating data

;with N1(C) as (select 0 union all select 0) -- 2 rows

,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows

,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows

,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows

,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows

,IDs(ID) as (select row_number() over (order by (select null)) from N5)

insert into dbo.UniqueCI(KeyValue, ID)

    select ID, ID from IDs;

insert into dbo.NonUniqueCINoDups(KeyValue, ID)

    select KeyValue, ID from dbo.UniqueCI;

insert into dbo.NonUniqueCIDups(KeyValue, ID)

    select KeyValue % 10, ID from dbo.UniqueCI;

      現在，讓我們看看每個表的聚集索引的物理統計資訊。其程式碼顯示在圖7-2，結果如圖7-1所示。

圖7 – 2  非唯一聚集索引:檢查聚集索引的行大小

select index_level, page_count, min_record_size_in_bytes as [min row size]

,max_record_size_in_bytes as [max row size]

,avg_record_size_in_bytes as [avg row size]

from

    sys.dm_db_index_physical_stats(db_id(),object_id(N'dbo.UniqueCI'), 1, null ,'DETAILED');

select index_level, page_count, min_record_size_in_bytes as [min row size]

    ,max_record_size_in_bytes as [max row size]

, avg_record_size_in_bytes as [avg row size]

from

sys.dm_db_index_physical_stats(db_id(),object_id(N'dbo.NonUniqueCINoDups'), 1, null,'DETAILED');

select index_level, page_count, min_record_size_in_bytes as [min row size]

    ,max_record_size_in_bytes as [max row size]

    ,avg_record_size_in_bytes as [avg row size]

from   sys.dm_db_index_physical_stats(db_id(),object_id(N'dbo.NonUniqueCIDups'), 1, null

,'DETAILED');

圖7 - 1。非唯一聚集索引:聚集索引的行大小

       即使表dbo.NonUniqueCINoDups中沒有重複的鍵值,表中還有兩個新增到行的額外位元組。SQL Server在資料的可變長度部分儲存一個uniquifier，和這兩個位元組由可變長度資料偏移陣列中的另一個條目新增。

      在這種情況下，當叢集索引具有重複值時，uniquifiers將再新增4個位元組，即導致總共6位元組的開銷。

      值得一提的是，在某些邊緣情況下，uniquifier使用的額外儲存空間可以減少資料頁上可以容納的行數。我們的示例演示了這種情況。你可以看到，表dbo.UniqueCI與其他兩個表相比使用的資料頁少了大約15%。 

       現在，讓我們看看uniquifier如何影響非叢集索引。清單7-3所示的程式碼建立三個表中的非聚集索引。圖7-2顯示了這些索引的物理統計資訊。

圖7-3 非唯一聚集索引:檢查非聚集索引的行大小

create nonclustered index IDX_UniqueCI_ID

on dbo.UniqueCI(ID);

create nonclustered index IDX_NonUniqueCINoDups_ID

on dbo.NonUniqueCINoDups(ID);

create nonclustered index IDX_NonUniqueCIDups_ID

on dbo.NonUniqueCIDups(ID);

select index_level, page_count, min_record_size_in_bytes as [min row size]

   ,max_record_size_in_bytes as [max row size]

   ,avg_record_size_in_bytes as [avg row size]

from

   sys. dm_db_index_physical_stats(db_id(), object_id(N'dbo.UniqueCI'), 2, null

,'DETAILED');

select index_level, page_count, min_record_size_in_bytes as [min row size]

   ,max_record_size_in_bytes as [max row size]

   ,avg_record_size_in_bytes as [avg row size]

from

sys.dm_db_index_physical_stats(db_id(),object_id(N'dbo.NonUniqueCINoDups'), 2, null,'DETAILED');

select index_level, page_count, min_record_size_in_bytes as [min row size]

,max_record_size_in_bytes as [max row size]

,avg_record_size_in_bytes as [avg row size]

from

sys.dm_db_index_physical_stats(db_id(),object_id(N'dbo.NonUniqueCIDups'), 2, null,'DETAILED');

圖7-2 不唯一聚集索引：非聚集索引大小

       dbo.NonUniqueCINoDups表中的非聚集索引沒有開銷。 你應該還記得，SQL Server不會將偏移量資訊儲存在NULL資料的尾隨列的可變長度偏移陣列中。儘管如此，uniquifier在dbo.NonUniqueCIDups表中也引入了8個位元組的開銷。 這八個位元組由一個4位元組的unquifier值，一個雙位元組的可變長度資料偏移陣列條目和一個儲存行中可變長度列數的雙位元組條目組成。

       我們可以通過以下方式總結uniquifier的儲存開銷。 對於具有uniquifier但為NULL的行，如果索引中至少有一個儲存NOT NULL值的可變長度列，那就會產生兩個位元組的開銷。 該開銷來自uniquifier列的可變長度偏移陣列條目。否則沒有開銷。

      在填充uniquifier的情況下，如果存在儲存非空值的可變長度列，則開銷為6個位元組。否則，開銷是8個位元組。

提示：如果預計聚簇索引值中存在大量重複項，可以將整數標識列作為最右邊的列新增到索引中，從而實現唯一性。 與uniquifiers引入的最多8位元組的不可預測儲存開銷相比，這將為每行增加一個4位元組的可預測儲存開銷。當你通過其該行的聚簇索引列使用該行時，這還可以提高單個查詢操作的效能。

      用最小化插入新行引起索引碎片化的方式設計聚簇索引是有好處的。實現這一點的方法之一是不斷增加聚簇索引值。 標識列上的索引就是一個這樣的例子。 另一個示例是使用插入時的當前系統時間填充的datetime列。

      然而，索引不斷增加會存在兩個潛在問題。第一個與統計有關。就像你在第3章中瞭解到的，當直方圖中沒有引數值時，SQL Server中的遺留基數估計器會低估基數。你應該將這種行為考慮到系統的統計維護策略中，除非你使用新的SQL Server 2014-2016基數估計值，該估計值假定在直方圖之外的資料具有類似於表中其他資料的分佈。

      下一個問題更復雜。 隨著索引的不斷增加，資料總是插入到索引的末尾。 一方面，它可以防止頁面拆分並減少碎片。 另一方面，它可能導致熱點，即當多個會話試圖修改相同的資料頁和/或分配新的頁或區段時發生的序列化延遲。SQL Server不允許多個會話更新相同的資料結構，而是通過序列化執行這些操作。

       除非系統以非常高的速率收集資料並且索引每秒處理數百個插入，否則熱點通常不是問題。 我們將在第27章“系統故障排除”中討論如何檢測此類問題。

       最後，如果系統有一組頻繁執行且重要的查詢，就要考慮到聚簇索引這時候是有好處的，它會優化它們。這解決了昂貴的金鑰查詢操作花銷並提高了系統的效能。

       即使可以使用覆蓋非聚簇索引來優化此類查詢，但它並不總是理想的解決方案。 在某些情況下，它需要你建立非常大的非聚簇索引，這將佔用磁碟和緩衝池中的大量儲存空間。

       另一個重要因素是修改列的頻率。將經常修改的列新增到非聚簇索引上需要SQL Server在多個位置更改資料，這會對系統的更新效能產生負面影響，並增加阻塞。

       儘管如此，並不總能設計滿足所有這些準則的聚簇索引。 此外，你不應將這些指南視為絕對要求。應該分析系統，業務需求，工作負載和查詢，並選擇適當的聚簇索引，即使它們違反了某些準則。

身份，序列和唯一識別符號

       人們通常選擇身份，序列和唯一識別符號作為聚簇索引鍵。 與前面的一樣，這種方法有其自身的優缺點。

       在此類上定義的聚簇索引是唯一的，靜態的和窄的。此外，身份和序列不斷增加的同時也減少了索引碎片。一個理想的用例是目錄實體表。作為示例，你可能會考慮到儲存客戶，文章或裝置列表的表。 這些表儲存數千甚至數百萬行，但是資料相對靜態，因此熱點不是問題。 此外，這些表通常由外來鍵引用並用於連線。 integer或bigint列上的索引非常緊湊和高效，這將提高查詢的效能。

注意：我們將在第8章“約束”中更詳細地討論外來鍵約束。

      在事務性表中，身份或序列列上的聚集索引效率較低，事務性表以非常高的速率收集大量資料，這是由於它們引入的潛在熱點造成的。

      另一方面，對於聚集索引和非聚集索引，uniqueidentifier很少是一個好的選擇。使用NEWID()函式生成的隨機值極大地增加了索引碎片。此外，uniqueidentifiers上的索引會降低批處理操作的效能。我們看一個示例並建立兩個表:一個表在標識列上具有聚簇索引，另一個表在uniqueidentifier列上具有聚簇索引。下一步，我們將在兩個表中插入65,536行。你可以在列表7-4中看到執行此操作的程式碼。

列表7-4 Uniqueidentifiers：表建立(

 ID int not null identity(1,1),

 Val int not null,

 Placeholder char(100) null

);

create unique clustered index IDX_IdentityCI_ID

on dbo.IdentityCI(ID);

create table dbo.UniqueidentifierCI

(

 ID uniqueidentifier not null

 constraint DEF_UniqueidentifierCI_ID

 default newid(),

 Val int not null,

 Placeholder char(100) null,

);

create unique clustered index IDX_UniqueidentifierCI_ID

on dbo.UniqueidentifierCI(ID)

go

;with N1(C) as (select 0 union all select 0) -- 2 rows

,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows

,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows

,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows

,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows

,IDs(ID) as (select row_number() over (order by (select null)) from N5)

insert into dbo.IdentityCI(Val)

 select ID from IDs;

;with N1(C) as (select 0 union all select 0) -- 2 rows

,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows

,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows

,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows

,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows

,IDs(ID) as (select row_number() over (order by (select null)) from N5)

insert into dbo.UniqueidentifierCI(Val)

 select ID from IDs;

        我的計算機上的執行時間和讀取次數如表7-1所示。 圖7-3顯示了兩個查詢的執行計劃。

表7-1 將資料插入表：執行統計

 

圖7-3 將資料插入表中：執行計劃

       就像你看到的，uniqueidentifier列上的索引有另一個排序運算子。SQL Server在插入之前對隨機生成的uniqueidentifier值進行排序，這種操作會降低查詢的效能。接下來我們在表中插入另一批行並檢查索引碎片。執行此操作的程式碼如列表7-5所示。圖7-4顯示了查詢的結果。   

列表7-5 Uniqueidentifiers：插入行並檢查碎片

;with N1(C) as (select 0 union all select 0) -- 2 rows

,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows

,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows

,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows

,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows

,IDs(ID) as (select row_number() over (order by (select null)) from N5)

insert into dbo.IdentityCI(Val)

 select ID from IDs;

;with N1(C) as (select 0 union all select 0) -- 2 rows

,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows

,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows

,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows

,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows

,IDs(ID) as (select row_number() over (order by (select null)) from N5)

insert into dbo.UniqueidentifierCI(Val)

 select ID from IDs;

select page_count, avg_page_space_used_in_percent, avg_fragmentation_in_percent

from sys.dm_db_index_physical_stats(db_id(),object_id(N'dbo.IdentityCI'),1,null,'DETAILED');

select page_count, avg_page_space_used_in_percent, avg_fragmentation_in_percent

from sys.dm_db_index_physical_stats(db_id(),object_id(N'dbo.UniqueidentifierCI'),1,null

,'DETAILED');

圖7-4。 索引碎片

       正如你所看到的，uniqueidentifier列上的索引嚴重碎片化，與標識列上的索引相比，它使用的資料頁大約多40％。

       在uniqueidentifier列的索引中的批量插入會變成在資料檔案的不同位置插入資料，當表太大這會出現繁重的隨機物理I / O. 這可能會降低操作效能。

                                                         個人經驗

       前段時間，我參與了一個系統的優化，該系統具有250 GB的表，其中包含一個聚簇索引和三個非聚簇索引。 其中一個非聚簇索引是uniqueidentifier列上的索引。通過刪除此索引，我們能夠將50,000行的批量插入從45秒加速到7秒。

       當你想要在uniqueidentifier列上建立索引時，有兩種常見方法。 第一個是支援跨多個數據庫的值保證唯一性。其中行可以插入到分散式系統的每個資料庫中。開發人員經常使用uniqueidentifiers來確保每個鍵值在系統範圍內都是唯一的。

      像這種實現的關鍵元素是如何生成鍵值。就像你已經看到的，NEWID()函式或客戶機程式碼中生成的隨機值會對系統性能產生負面影響。但是，你可以使用NEWSEQUENTIALID()函式，該函式會生成遞增的唯一的值(SQL Server不時重置它們的基值)。使用NEWSEQUENTIALID()函式生成的uniqueidentifier列上的索引類似於標識列和序列列上的索引;但是，你要記住，uniqueidentifier資料型別使用16位元組的儲存空間，而4位元組的int或8位元組的bigint資料型別。

        作為替代解決方案，你也可以建立兩列的複合索引（InstallationIdUnique_Id_Within_Installation）。 兩列的組合保證了多個安裝和資料庫的唯一性，並且比獨特識別符號使用更少的儲存空間。 你可以使用整數標識或序列來生成Unique_Id_Within_Installation值，這將減少索引的碎片。

       在需要跨資料庫後所有實體生成唯一鍵值的情況下，可以考慮跨所有實體使用單個sequence物件。這種方法可以滿足需求，但是使用到比唯一識別符號更小的資料型別。

        另一個常見方法是安全性，其中uniqueidentifier值用作安全性令牌或隨機物件編號。 不幸的是，你無法在此方案中使用NEWSEQUENTIALID（）函式，因為可以猜測該函式返回的下一個值。

      在這種情況下，一種可能的改進是不在uniqueidentifier列上建立索引，而是使用CHECKSUM（）函式建立計算列，然後對其進行索引。 程式碼如列表7-6所示。

列表7-6 使用CHECKSUM（）：表結構

create table dbo.Articles

(

 ArticleId int not null identity(1,1),

 ExternalId uniqueidentifier not null

constraint DEF_Articles_ExternalId

default newid(),

ExternalIdCheckSum as checksum(ExternalId),

/* Other Columns */

);

create unique clustered index IDX_Articles_ArticleId

on dbo.Articles(ArticleId);

create nonclustered index IDX_Articles_ExternalIdCheckSum

on dbo.Articles(ExternalIdCheckSum);

提示：你可以索引計算列而不保留它

      儘管IDX_Articles_ExternalIdCheckSum索引非常分散，但與uniqueidentifier列上的索引（4位元組金鑰與16位元組）相比，它更緊湊。 它還提高了批處理操作的效能，因為更快的排序，所以也需要更小的記憶體來進行。

       你必須記住的一件事是CHECKSUM（）函式的結果不保證是唯一的。你應該在查詢中包含兩個謂詞，如列表7-7所示

列表7-7 使用CHECKSUM（）：選擇資料

select ArticleId /* Other Columns */

from dbo.Articles

where checksum(@ExternalId) = ExternalIdCheckSum and ExternalId = @ExternalId

提示:如果需要索引大於900/ 1700位元組的字串列(這是非叢集索引鍵的最大大小)，可以使用相同的技術。即使這樣的索引不支援範圍掃描操作，它也可以用於點查詢。