SQL Server非聚集索引概述
此文章主要向大家描述的是SQL Server非聚集索引（Noclustered Index Indications），在實(shí)際操作中SQL Server 2000數(shù)據(jù)庫可以允許你在一個(gè)表上最大程度的創(chuàng)建249個(gè)非聚集索引。直到表變得非常巨大，一個(gè)非聚集索引實(shí)際所占用的空間與日益增長(zhǎng)的訪問性能相比是微不足道的。
然而，時(shí)刻牢記：隨著你在系統(tǒng)添加更多索引，數(shù)據(jù)修改語句由于索引性能的負(fù)擔(dān)會(huì)變得更慢。
當(dāng)定義SQL Server非聚集索引時(shí)，你也想在選擇性高的列上定義索引（也就是，具有低密度值的列）這樣它們能被優(yōu)化器來使用。一個(gè)非聚集索引中的大量重復(fù)值經(jīng)常使得使用非聚集索引比表掃描代價(jià)更高（按照I/O）。讓我們一起來看一個(gè)假設(shè)的例子：
- Sql代碼
- Select title from titles
- Where price between $5 and $10
- Select title from titles
- Where price between $5 and $10
假設(shè)你在范圍內(nèi)有1，000，000行；這些1，000，000行隨機(jī)分散在整個(gè)表中。盡管索引葉級(jí)擁有全部的有序索引行，但在最壞情況下，一次讀一個(gè)數(shù)據(jù)行也將要求一個(gè)書簽查找。
這樣，在最壞情況下使用SQL Server非聚集索引來進(jìn)行范圍檢索的I/O估計(jì)如下：
引用
非聚集索引的層數(shù)
+用于發(fā)現(xiàn)所有匹配行的掃描的索引頁數(shù)
+ 匹配的行數(shù) × 每個(gè)書簽查找的頁數(shù)
假如你的表上沒有聚集索引，那書簽僅僅是一個(gè)包括頁和行的指針，當(dāng)發(fā)現(xiàn)匹配的數(shù)據(jù)行時(shí)需要讀取一個(gè)數(shù)據(jù)頁。假如范圍內(nèi)有1，000，000行，當(dāng)該表沒有聚集索引時(shí)，借助非聚集索引的最壞情況的估計(jì)是：
引用
查找所有書簽需要讀取的索引頁數(shù)
+1，000，000匹配行 × 1數(shù)據(jù)頁的讀取
= 1，000，000 +I/Os
如果表中有聚集索引，書簽就是一個(gè)代表數(shù)據(jù)行的聚集索引鍵，用書簽來查找匹配的行要求搜索聚集索引樹來定位數(shù)據(jù)行。假設(shè)聚集索引有兩級(jí)非葉子節(jié)點(diǎn)，它將需要讀取三頁來在數(shù)據(jù)頁上查找每個(gè)滿足條件的行。如果范圍內(nèi)有1，000，000行，那么借助聚集索引的SQL Server非聚集索引來查找數(shù)據(jù)，在最壞情況下它的代價(jià)估計(jì)如下：
引用
查找所有書簽所讀取的索引頁的個(gè)數(shù)
+1，000，000匹配的行 * 每個(gè)書簽查找需求的3頁
=3，000，00+I/Os
把每種情況與表掃描相對(duì)比。如果整個(gè)表占用了50，000頁，那么一個(gè)全表掃描將只花費(fèi)50，000 I/O。所以，在這個(gè)例子中，一個(gè)表掃描實(shí)際將比用非聚集索引更有效。
下面的指南幫助你識(shí)別非聚集索引的潛在的候選者。
SARG或join子句中引用的相對(duì)來說具有較高的選擇性（密度值低）的列。
Where子句和order by子句都引用的列。
當(dāng)使用非聚集索引來檢索數(shù)據(jù)行時(shí)，它們按照非聚集索引鍵的順序被檢索出來。如果結(jié)果集也需要按照SQL Server非聚集索引進(jìn)行排序，SQL Server能避免對(duì)結(jié)果集重新排序，這樣可實(shí)現(xiàn)一個(gè)更有效的查詢。下面就是這樣一個(gè)例子：
- Sql代碼
- Select * from authors
- Where state like "c%"
- Order by state
- Select * from authors
- Where state like "c%"
- Order by state
一般情況下，非聚集索引對(duì)單行查找（single-row lookup），連接（join），有高選擇性的列的查詢，小范圍檢索的查詢有用。當(dāng)你考慮非聚集索引的設(shè)計(jì)時(shí)也不要忽略了覆蓋索引的優(yōu)點(diǎn)，下節(jié)將會(huì)講到。
索引覆蓋（Index Covering）
索引覆蓋是這樣一種情況，查詢中的select 和where子句中所需要的信息都能在非聚集索引中找到。因?yàn)榉蔷奂饕艘粋€(gè)對(duì)應(yīng)于表中每個(gè)數(shù)據(jù)行的一個(gè)葉子行，SQL Server能從非聚集索引的葉子行來滿足查詢。這導(dǎo)致了數(shù)據(jù)檢索的更快，因?yàn)樗械男畔⒛軓乃饕撝兄苯荧@得，并且避免了SQL Server查找數(shù)據(jù)頁。
因?yàn)榉蔷奂饕娜~子頁都連接在一起，索引的葉級(jí)可以像表中的數(shù)據(jù)頁一樣進(jìn)行掃描，因?yàn)轫摷?jí)行都典型比數(shù)據(jù)行要小，一個(gè)覆蓋了查詢的非聚集索引將比同樣列的聚集索引更快，因?yàn)樾枰x取的頁數(shù)要更少。
在下面的例子中，quthors表中的關(guān)于au_lname 和au_fname的SQL Server非聚集索引將覆蓋查詢，因?yàn)榻Y(jié)果中的列和SARG都能從索引中提取出來：
- Sql代碼
- Select au_lname, au_fname
- From authors
- Where au_lname like "M%"
- GO
- Select au_lname, au_fname
- From authors
- Where au_lname like "M%"
- GO
其他使用聚合函數(shù)（MIN AVG SUM COUNT）的查詢或者僅僅檢查是否存在的查詢也能從索引覆蓋中獲益。下面是一些能夠利用索引覆蓋優(yōu)點(diǎn)的查詢：
- Sql代碼
- Select count (au_lname) from authors where au_lname like 'm%'
- Select count (*) from authors where au_lname like 'm%'
- Select count (*) from authors
- Select count (au_lname) from authors where au_lname like 'm%'
- Select count (*) from authors where au_lname like 'm%'
- Select count (*) from authors
你可能會(huì)奇怪最后一個(gè)查詢，它甚至沒有一個(gè)具體的SARG，怎么還能使用索引。SQL Server知道非聚集索引的特性，一個(gè)非聚集索引為表中的每行數(shù)據(jù)都包含了一行；它能夠簡(jiǎn)單的計(jì)算任何一個(gè)非聚集索引的行數(shù)，而不需要掃描整個(gè)表。對(duì)最后一個(gè)查詢，SQL Server選擇最小的SQL Server非聚集索引——也就是，具有最少的葉子頁的索引。
向非聚集索引添加列使得發(fā)生索引覆蓋是一種提高查詢響應(yīng)時(shí)間的常見方法?？紤]下面的查詢：
- Sql代碼
- Select royalty from titles
- Where price between $10 and $ 20
- Select royalty from titles
- Where price between $10 and $ 20
如果你僅在price列上創(chuàng)建索引，SQL Server能發(fā)現(xiàn)滿足price在該范圍的索引中的行，但是它還需要訪問數(shù)據(jù)行來檢索royalty。范圍中有100行，最壞情況下檢索數(shù)據(jù)所花費(fèi)的IO代價(jià)計(jì)算如下：
引用
索引的級(jí)數(shù)
+查找匹配行的索引頁的數(shù)
+100 * 每個(gè)書簽查找頁數(shù)
如果royalty列添加到了price列索引中了，索引能被掃描來檢索結(jié)果，而不是進(jìn)行書簽查找，這樣具有更快的查詢響應(yīng)。使用索引覆蓋的IO代價(jià)將只是：
引用
索引級(jí)數(shù)
+查找匹配行的索引頁的數(shù)
引用
注意：
當(dāng)考慮添加索引來利用索引覆蓋時(shí)，小心使得索引變得太寬。當(dāng)索引行的寬度接近與數(shù)據(jù)行寬度時(shí)，覆蓋的優(yōu)點(diǎn)將失去，因?yàn)樵黾恿巳~級(jí)頁的數(shù)目。當(dāng)索引的葉級(jí)頁的數(shù)目接近了表中頁的數(shù)目，索引級(jí)數(shù)也增加了，那么索引掃描的時(shí)間就開始接近于表掃描時(shí)間了。
另外，如果你添加對(duì)到索引中的列頻繁修改，數(shù)據(jù)行中列的任何修改也會(huì)波及到索引中。這增加了維護(hù)的負(fù)擔(dān)，也會(huì)影響修改的性能。
正如第33章討論的那樣，當(dāng)在一個(gè)表上創(chuàng)建了 一個(gè)聚集索引，聚集鍵會(huì)被所有的SQL Server非聚集索引引用，作為書簽來定位實(shí)際的數(shù)據(jù)行。聚集鍵實(shí)際就是一些列，它們構(gòu)成了聚集索引和它們的數(shù)據(jù)值。這種特性有時(shí)也能導(dǎo)致索引覆蓋。
例如，假設(shè)suthors表在au_lname au_fname列上建立聚集索引，并有一個(gè)定義在au_id的非聚集索引。非聚集索引的每行都包含了與數(shù)據(jù)行對(duì)應(yīng)的au_lname au_fname聚集鍵值。因?yàn)檫@個(gè)原因，下面查詢將被非聚集索引覆蓋：
- Sql代碼
- select au_lname, au_fname
- from authors
- where au_id like '123%'
- select au_lname, au_fname
- from authors
- where au_id like '123%'
以上的相關(guān)內(nèi)容就是對(duì)SQL Server非聚集索引（Noclustered Index Indications）的介紹，望你能有所收獲。
【編輯推薦】
