SQL Server聚集索引的指示簡(jiǎn)介
以下的文章主要向大家講述的是SQL Server聚集索引指示（Cluster Index Indications），我們大家都知道借助聚集索引來(lái)搜索行一般的情況下借助非聚集索引來(lái)搜索行快，其主要有兩個(gè)原因。原因一是聚集索引只包含了一個(gè)指向頁(yè)的指針而不是指向單個(gè)數(shù)據(jù)行的指針。
SQL Server聚集索引指示（Cluster Index Indications）：
所以，一個(gè)聚集索引比非聚集索引更緊湊。因?yàn)榫奂饕〔⑶也恍枰~外的書(shū)簽查找來(lái)發(fā)現(xiàn)匹配的行，而且比相似定義的非SQL Server聚集索引可通過(guò)更少的頁(yè)的讀操作來(lái)發(fā)現(xiàn)行。
第二個(gè)原因是SQL Server聚集索引的表中的數(shù)據(jù)物理上就是按照聚集鍵來(lái)存放，搜索重復(fù)值或者聚集鍵的一個(gè)范圍值更快；行之間相互鄰接并且SQL Server能簡(jiǎn)單定位***個(gè)滿足條件的行然后順序搜索直到發(fā)現(xiàn)***一個(gè)滿足條件的行。然而，每個(gè)表上只能創(chuàng)建一個(gè)聚集索引，你必須明智地選擇在哪個(gè)列或哪些列上來(lái)定義聚集索引。
如果你要求在一個(gè)表上只創(chuàng)建一個(gè)單獨(dú)的索引，那創(chuàng)建聚集索引有很大優(yōu)勢(shì)；則結(jié)果就是在修改、插入和刪除時(shí)的負(fù)擔(dān)將比創(chuàng)建非聚集索引的負(fù)擔(dān)要小的多。
默認(rèn)情況下，表中的主鍵將被定義為聚集的唯一索引。在大多數(shù)應(yīng)用中，表上的主鍵列總是以單行查找的方式來(lái)檢索。對(duì)于單行查找，一個(gè)非聚集索引通常比一個(gè)相似的聚集索引花費(fèi)更少的I/O代價(jià)。你或者你的用戶真正注意過(guò)讀三頁(yè)去檢索單個(gè)數(shù)據(jù)行和四到六頁(yè)去檢索單個(gè)數(shù)據(jù)行之間的區(qū)別嗎？不一定。然而，如果你執(zhí)行一個(gè)范圍檢索，比如查找last name，你將會(huì)注意到掃描表的10%和使用全表掃描來(lái)發(fā)現(xiàn)行之間的區(qū)別嗎？一定會(huì)的。
根據(jù)這種思想，你可能想為你的主鍵創(chuàng)建一個(gè)唯一的非聚集索引，并選擇其他候選列做為你的聚集索引。下面就是一些指南，可以幫助你來(lái)選擇聚集索引的潛在的候選者：
一些頻繁搜索的具有許多重復(fù)值的列，比如， where last_name = 'Smith' 因?yàn)閿?shù)據(jù)物理上是有序的，所有的重復(fù)值將聚集在一起。任何一個(gè)對(duì)該鍵值的查詢將會(huì)用最小的I/O來(lái)發(fā)現(xiàn)所有的值。SQL Server 定位***個(gè)滿足SARG的行，然后按順序掃描數(shù)據(jù)直到找到***一個(gè)滿足SARG的行。
經(jīng)常被ORDER BY子句指定的列。
因?yàn)閿?shù)據(jù)已經(jīng)是有序的，如果ORDER BY 是關(guān)于聚集索引的，那SQL Server將避免重新排序。記?。杭词箤?duì)一個(gè)表掃描，數(shù)據(jù)也將會(huì)按照聚集鍵值的順序檢索，因?yàn)閿?shù)據(jù)表上的數(shù)據(jù)是按照聚集鍵值排序。
經(jīng)常按照一個(gè)范圍值進(jìn)行查詢的列，例如，Where price between ￥10 and ￥20 使用SQL Server聚集索引首先定位***個(gè)滿足范圍條件的行。因?yàn)楸碇械男邪错樞蚺帕校琒QL Server能簡(jiǎn)單按順序掃描數(shù)據(jù)頁(yè)直到***個(gè)滿足范圍的條件的行。當(dāng)滿足條件的結(jié)果集非常大，從執(zhí)行的邏輯I/O來(lái)講，聚集索引掃描將比借助非聚集索引重復(fù)進(jìn)行書(shū)簽查找更有效。
除了主鍵外，頻繁使用在join子句中的列。聚集索引趨向于比非聚集索引更?。幻總€(gè)查找需要頁(yè)的I/O一般來(lái)講比非聚集索引更少。當(dāng)join許多記錄時(shí)這種區(qū)別將是巨大的。一兩個(gè)額外的讀頁(yè)操作好像對(duì)一個(gè)單行檢索來(lái)說(shuō)不多，但是把這些額外的對(duì)100，000join迭代的讀頁(yè)操作相加，你會(huì)看到總共100,000到200,00讀頁(yè)操作。
選擇聚集索引鍵時(shí)應(yīng)滿足四個(gè)特點(diǎn)：
Narrow（窄，即長(zhǎng)度短）
Unique（唯一性）
Unchanging（不變化）
Ever increasing（不斷增長(zhǎng)）
當(dāng)你考慮聚集索引列時(shí)，你可能想嘗試在相對(duì)靜態(tài)的列上創(chuàng)建聚集索引，來(lái)最小化由于索引列的修改而引起的數(shù)據(jù)行重新排序。任何時(shí)間當(dāng)聚集索引的鍵值改變了，所有把聚集索引作為書(shū)簽的非聚集索引都需要被修改。
盡量避免在以單調(diào)形式插入的順序的鍵字段上創(chuàng)建聚集索引，比如一個(gè)標(biāo)識(shí)列（identity column）。這會(huì)在表的末尾創(chuàng)建一個(gè)"熱點(diǎn)"(hot spot)，結(jié)果會(huì)在表和索引的的末尾導(dǎo)致鎖競(jìng)爭(zhēng)和死鎖。另外，聚集索引也不會(huì)重用以前數(shù)據(jù)頁(yè)中的空間，因?yàn)樗行碌男卸寂旁跀?shù)據(jù)表的末尾。這種情況造成了空間的浪費(fèi)和你的表的增長(zhǎng)會(huì)比預(yù)期的要大。一般的建議是，盡量在一個(gè)有某種隨機(jī)分布的數(shù)據(jù)值上建立索引。盡量選擇一個(gè)使得插入和修改活動(dòng)散布在整個(gè)表的聚集鍵。一些能夠使得數(shù)據(jù)隨機(jī)化的候選SQL Server聚集索引包括下列：
出生日期
Last name first name
郵編
一個(gè)隨機(jī)hash key（通常只當(dāng)沒(méi)有其他實(shí)際列可以作為好的候選的聚集索引時(shí)才使用）
在整個(gè)表上散布你的數(shù)據(jù)有助于最小化頁(yè)競(jìng)爭(zhēng)，同時(shí)也提供了更有效的空間利用。如果序列鍵是你的主鍵，你仍能用一個(gè)唯一、非聚集索引來(lái)提供一個(gè)訪問(wèn)路徑并維護(hù)主鍵的唯一性。
因?yàn)槟阒荒芤砸环N方式對(duì)表上的數(shù)據(jù)進(jìn)行物理排序，你只能有一個(gè)聚集索引。你想索引的其它列只能被定義為非SQL Server聚集索引。
【編輯推薦】
