資料庫索引演算法

⑴ 從軟體開發的角度看，資料庫的索引有哪幾種傳統的實現方式

在Oracle中的索引可以分為：B樹索引、點陣圖索引、反向鍵索引、基於函數的索引、簇索引、全局索引、局部索引等

⑵ 資料庫索引的底層實現是什麼數據結構

關於資料庫索引的數據結構，大多數資料庫都是採用B樹。可參照文章：
http://blog.csdn.net/Ant_Yan/archive/2008/09/15/2932068.aspx

非主鍵索引需要在數據表本身的存儲空間外額外開銷存儲空間，所以在更新的時候可能不僅要更新數據表本身，還要更新非主鍵索引，更新內容更多了，所以導致速度降低。反過來，如果數據表中的數據按照主鍵索引的順序存儲，更新的時候就沒有額外的開銷。

非主鍵索引對提高查詢速度來講，主要的方面是：檢索的條件(where...)如果命中對應的非主鍵索引的話，就不需要對數據表做全表掃描，效率肯定是大大提高。（索引的創建和使用是資料庫設計和優化的重要部分，是一個資料庫程序員的必修課，不同資料庫系統的語法不同，但是原理基本相同）;
另一方面，也有如下的可能：如果檢索結果的欄位包含在非主鍵索引中，即使對非主鍵索引做全掃描，也比對整表欄位做全掃描快，因為只有非主鍵索引本身的數據需要從存儲設備調入內存，節約了IO時間。
不過一般說索引對查詢速度的影響，主要指第一種情況。

⑶ 資料庫索引是什麼，有什麼用，怎麼用

1、資料庫索引是什麼，有什麼用

資料庫索引是對資料庫表中一列或多列的值進行排序的一種結構，使用索引可快速訪問資料庫表中的特定信息。如果想按特定職員的姓來查找他或她，則與在表中搜索所有的行相比，索引有助於更快地獲取信息。

索引的一個主要目的就是加快檢索表中數據的方法，亦即能協助信息搜索者盡快的找到符合限制條件的記錄ID的輔助數據結構。

2、資料庫索引的用法

當表中有大量記錄時，若要對表進行查詢，第一種搜索信息方式是全表搜索，是將所有記錄一一取出，和查詢條件進行一一對比，然後返回滿足條件的記錄，這樣做會消耗大量資料庫系統時間，並造成大量磁碟I/O操作；

第二種就是在表中建立索引，然後在索引中找到符合查詢條件的索引值，最後通過保存在索引中的ROWID（相當於頁碼）快速找到表中對應的記錄。

索引是一個單獨的、物理的資料庫結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識值的數據頁的邏輯指針清單。

(3)資料庫索引演算法擴展閱讀：

一、索引的原理：

對要查詢的欄位建立索引其實就是把該欄位按照一定的方式排序；建立的索引只對該欄位有用，如果查詢的欄位改變，那麼這個索引也就無效了，比如圖書館的書是按照書名的第一個字母排序的，那麼你想要找作者叫張三的就不能用改索引了；還有就是如果索引太多會降低查詢的速度。

二、資料庫索引的特點：

1、避免進行資料庫全表的掃描，大多數情況，只需要掃描較少的索引頁和數據頁，而不是查詢所有數據頁。而且對於非聚集索引，有時不需要訪問數據頁即可得到數據。

2、聚集索引可以避免數據插入操作，集中於表的最後一個數據頁面。

3、在某些情況下，索引可以避免排序操作。

⑷ 資料庫索引為什麼會提高查詢速度

你的理解其實沒啥問題。索引就是通過事先排好序，從而在查找時可以應用二分查找等高效率的演算法。
一般的順序查找，復雜度為O(n)，而二分查找復雜度為O(log2n)。當n很大時，二者的效率相差及其懸殊。

舉個例子：
表中有一百萬條數據，需要在其中尋找一條特定id的數據。如果順序查找，平均需要查找50萬條數據。而用二分法，至多不超過20次就能找到。二者的效率差了2.5萬倍！

⑸ 關於資料庫索引的使用

查詢條件中用到的欄位才會走索引。 如果select * from stu where name = "test"; 這個就走索引了。當你表裡有百萬 千萬數據的時候，走索引的演算法差不多是ln(O)

⑹ 常見的數據檢索演算法有哪些資料庫都採用什麼樣的檢索方式如何提高檢索的效率

您好，你的問題，我之前好像也遇到過，以下是我原來的解決思路和方法，希望能幫助到你，若有錯誤，還望見諒！信息檢索方法包括：普通法、追溯法和分段法。1、普通法是利用書目、文摘、索引等檢索工具進行文獻資料查找的方法。運用這種方法的關鍵在於熟悉各種檢索工具的性質、特點和查找過程，從不同角度查找。普通法又可分為順檢法和倒檢法。2、追溯法是利用已有文獻所附的參考文獻不斷追蹤查找的方法，在沒有檢索工具或檢索工具不全時，此法可獲得針對性很強的資料，查准率較高，查全率較差。3、分段法是追溯法和普通法的綜合，它將兩種方法分期、分段交替使用，直至查到所需資料為止。(6)資料庫索引演算法擴展閱讀檢索原因信息檢索是獲取知識的捷徑美國普林斯頓大學物理系一個年輕大學生名叫約瀚·菲利普，在圖書館里借閱有關公開資料，僅用四個月時間，就畫出一張製造原子彈的設計圖。他設計的原子彈，體積小(棒球大小)、重量輕(7.5公斤)、威力大(相當廣島原子彈3/4的威力)，造價低(當時僅需兩千美元)，致使一些國家（法國、巴基斯坦等）紛紛致函美國大使館，爭相購買他的設計拷貝。二十世紀七十年代，美國核專家泰勒收到一份題為《製造核彈的方法》的報告，他被報告精湛的技術設計所吸引，驚嘆地說：「至今我看到的報告中，它是最詳細、最全面的一份。」但使他更為驚異的是，這份報告竟出於哈佛大學經濟專業的青年學生之手，而這個四百多頁的技術報告的全部信息來源又都是從圖書館那些極為平常的、完全公開的圖書資料中所獲得的。參考資料來源：網路——信息檢索，非常感謝您的耐心觀看，如有幫助請採納，祝生活愉快！謝謝！

⑺ 資料庫索引的實現原理

資料庫索引的實現原理
一、概述資料庫索引，是資料庫管理系統中一個排序的數據結構，以協助快速查詢、更新資料庫表中數據。索引的實現通常使用B樹及其變種B+樹。在數據之外，資料庫系統還維護著滿足特定查找演算法的數據結構，這些數據結構以某種方式引用(指向)數據，這樣就可以在這些數據結構上實現高級查找演算法。這種數據結構，就是索引。其實說穿了，索引問題就是一個查找問題。二、索引的原理當我們的業務產生了大量的數據時，查找數據的效率問題也就隨之而來，所以我們可以通過為表設置索引，而為表設置索引要付出代價的：一是增加了資料庫的存儲空間，二是在插入和修改數據時要花費較多的時間(因為索引也要隨之變動)。
上圖展示了一種可能的索引方式。左邊是數據表，一共有兩列七條記錄，最左邊的是數據記錄的物理地址(注意邏輯上相鄰的記錄在磁碟上也並不是一定物理相鄰的)。為了加快Col2的查找，可以維護一個右邊所示的二叉查找樹，每個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針，這樣就可以運用二叉查找在O(log2n)的復雜度內獲取到相應數據。索引是建立在資料庫表中的某些列的上面。在創建索引的時候，應該考慮在哪些列上可以創建索引，在哪些列上不能創建索引。一般來說，應該在這些列上創建索引：在經常需要搜索的列上，可以加快搜索的速度;在作為主鍵的列上，強制該列的唯一性和組織表中數據的排列結構;在經常用在連接的列上，這些列主要是一些外鍵，可以加快連接的速度;在經常需要根據范圍進行搜索的列上創建索引，因為索引已經排序，其指定的范圍是連續的;在經常需要排序的列上創建索引，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間;在經常使用在WHERE子句中的列上面創建索引，加快條件的判斷速度。創建索引可以大大提高系統的性能第一，通過創建唯一性索引，可以保證資料庫表中每一行數據的唯一性。第二，可以大大加快數據的檢索速度，這也是創建索引的最主要的原因。第三，可以加速表和表之間的連接，特別是在實現數據的參考完整性方面特別有意義。第四，在使用分組和排序子句進行數據檢索時，同樣可以顯著減少查詢中分組和排序的時間。第五，通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能。也許會有人要問：增加索引有如此多的優點，為什麼不對表中的每一個列創建一個索引呢?因為，增加索引也有許多不利的方面。創建索引的弊端第一，創建索引和維護索引要耗費時間，這種時間隨著數據量的增加而增加。第二，索引需要佔物理空間，除了數據表占數據空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。第三，當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。同樣，對於有些列不應該創建索引。一般來說，不應該創建索引的的這些列具有下列特點：第一，對於那些在查詢中很少使用或者參考的列不應該創建索引。這是因為，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。第二，對於那些只有很少數據值的列也不應該增加索引。這是因為，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比例，即需要在表中搜索的數據行的比例很大。增加索引，並不能明顯加快檢索速度。第三，對於那些定義為text, image和bit數據類型的列不應該增加索引。這是因為，這些列的數據量要麼相當大，要麼取值很少。第四，當修改性能遠遠大於檢索性能時，不應該創建索引。這是因為，修改性能和檢索性能是互相矛盾的。當增加索引時，會提高檢索性能，但是會降低修改性能。當減少索引時，會提高修改性能，降低檢索性能。因此，當修改性能遠遠大於檢索性能時，不應該創建索引。三、索引的類型根據資料庫的功能，可以在資料庫設計器中創建三種索引：唯一索引、主鍵索引和聚集索引。唯一索引唯一索引是不允許其中任何兩行具有相同索引值的索引。當現有數據中存在重復的鍵值時，大多數資料庫不允許將新創建的唯一索引與表一起保存。資料庫還可能防止添加將在表中創建重復鍵值的新數據。例如，如果在employee表中職員的姓(lname)上創建了唯一索引，則任何兩個員工都不能同姓。主鍵索引資料庫表經常有一列或列組合，其值唯一標識表中的每一行。該列稱為表的主鍵。在資料庫關系圖中為表定義主鍵將自動創建主鍵索引，主鍵索引是唯一索引的特定類型。該索引要求主鍵中的每個值都唯一。當在查詢中使用主鍵索引時，它還允許對數據的快速訪問。聚集索引在聚集索引中，表中行的物理順序與鍵值的邏輯(索引)順序相同。一個表只能包含一個聚集索引。如果某索引不是聚集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非聚集索引相比，聚集索引通常提供更快的數據訪問速度。四、局部性原理與磁碟預讀由於存儲介質的特性，磁碟本身存取就比主存慢很多，再加上機械運動耗費，磁碟的存取速度往往是主存的幾百分分之一，因此為了提高效率，要盡量減少磁碟I/O。為了達到這個目的，磁碟往往不是嚴格按需讀取，而是每次都會預讀，即使只需要一個位元組，磁碟也會從這個位置開始，順序向後讀取一定長度的數據放入內存。這樣做的理論依據是計算機科學中著名的局部性原理：當一個數據被用到時，其附近的數據也通常會馬上被使用。程序運行期間所需要的數據通常比較集中。由於磁碟順序讀取的效率很高(不需要尋道時間，只需很少的旋轉時間)，因此對於具有局部性的程序來說，預讀可以提高I/O效率。預讀的長度一般為頁(page)的整倍數。頁是計算機管理存儲器的邏輯塊，硬體及操作系統往往將主存和磁碟存儲區分割為連續的大小相等的塊，每個存儲塊稱為一頁(在許多操作系統中，頁得大小通常為4k)，主存和磁碟以頁為單位交換數據。當程序要讀取的數據不在主存中時，會觸發一個缺頁異常，此時系統會向磁碟發出讀盤信號，磁碟會找到數據的起始位置並向後連續讀取一頁或幾頁載入內存中，然後異常返回，程序繼續運行。五、B樹和B+樹數據結構1、B樹B樹中每個節點包含了鍵值和鍵值對於的數據對象存放地址指針，所以成功搜索一個對象可以不用到達樹的葉節點。成功搜索包括節點內搜索和沿某一路徑的搜索，成功搜索時間取決於關鍵碼所在的層次以及節點內關鍵碼的數量。在B樹中查找給定關鍵字的方法是：首先把根結點取來，在根結點所包含的關鍵字K1,…,kj查找給定的關鍵字(可用順序查找或二分查找法)，若找到等於給定值的關鍵字，則查找成功;否則，一定可以確定要查的關鍵字在某個Ki或Ki+1之間，於是取Pi所指的下一層索引節點塊繼續查找，直到找到，或指針Pi為空時查找失敗。2、B+樹B+樹非葉節點中存放的關鍵碼並不指示數據對象的地址指針，非也節點只是索引部分。所有的葉節點在同一層上，包含了全部關鍵碼和相應數據對象的存放地址指針，且葉節點按關鍵碼從小到大順序鏈接。如果實際數據對象按加入的順序存儲而不是按關鍵碼次數存儲的話，葉節點的索引必須是稠密索引，若實際數據存儲按關鍵碼次序存放的話，葉節點索引時稀疏索引。B+樹有2個頭指針，一個是樹的根節點，一個是最小關鍵碼的葉節點。所以 B+樹有兩種搜索方法：一種是按葉節點自己拉起的鏈表順序搜索。一種是從根節點開始搜索，和B樹類似，不過如果非葉節點的關鍵碼等於給定值，搜索並不停止，而是繼續沿右指針，一直查到葉節點上的關鍵碼。所以無論搜索是否成功，都將走完樹的所有層。B+ 樹中，數據對象的插入和刪除僅在葉節點上進行。這兩種處理索引的數據結構的不同之處：1、B樹中同一鍵值不會出現多次，並且它有可能出現在葉結點，也有可能出現在非葉結點中。而B+樹的鍵一定會出現在葉結點中，並且有可能在非葉結點中也有可能重復出現，以維持B+樹的平衡。2、因為B樹鍵位置不定，且在整個樹結構中只出現一次，雖然可以節省存儲空間，但使得在插入、刪除操作復雜度明顯增加。B+樹相比來說是一種較好的折中。3、B樹的查詢效率與鍵在樹中的位置有關，最大時間復雜度與B+樹相同(在葉結點的時候)，最小時間復雜度為1(在根結點的時候)。而B+樹的時候復雜度對某建成的樹是固定的。六、B/+Tree索引的性能分析到這里終於可以分析B-/+Tree索引的性能了。上文說過一般使用磁碟I/O次數評價索引結構的優劣。先從B-Tree分析，根據B-Tree的定義，可知檢索一次最多需要訪問h個節點。資料庫系統的設計者巧妙利用了磁碟預讀原理，將一個節點的大小設為等於一個頁，這樣每個節點只需要一次I/O就可以完全載入。為了達到這個目的，在實際實現B-Tree還需要使用如下技巧：每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁里，加之計算機存儲分配都是按頁對齊的，就實現了一個node只需一次I/O。B-Tree中一次檢索最多需要h-1次I/O(根節點常駐內存)，漸進復雜度為O(h)=O(logdN)。一般實際應用中，出度d是非常大的數字，通常超過100，因此h非常小(通常不超過3)。而紅黑樹這種結構，h明顯要深的多。由於邏輯上很近的節點(父子)物理上可能很遠，無法利用局部性，所以紅黑樹的I/O漸進復雜度也為O(h)，效率明顯比B-Tree差很多。綜上所述，用B-Tree作為索引結構效率是非常高的。

⑻ 談談資料庫索引 用自己話說

索引是個大學問，三言兩語還說不清楚，試試：
1. 為什麼要索引？主要提高性能，如查詢速度。
2.索引為什麼能提高性能？ 這個簡單，想想那種帶標簽的英文字典（注意不是指目錄）。按26個字母分組。假設你要找friend這個詞，你只要找到F標簽頁，再順序找這個詞。如果沒有這個標簽，你得從A一直找到F，再找到這個詞。快速定位到F標簽頁，就是索引提高性能的原理。具體到資料庫，標簽也可以現象為為每個磁碟塊建的索引塊，裡面表明了本磁碟塊存儲的數據范圍（索引值范圍）。
3. 索引的種類？用老師的點名冊做例子，除了按學號排序，還可以按成績排序。成績也就成了一種索引。先按成績，再按學號排序，也就多級索引。按不同的角度還可以區分好多類，建議學習專業書籍。
4. 索引的演算法？資料庫一般用B+樹的索引演算法。這個是個多叉的平衡的樹，平衡的概念是每個分支上的葉子節點差不太多。此樹一般高度（深度）不大，插入開銷比較可控。查詢性能優異。
5. 你再問吧。。
看我這么辛苦的碼字，為了啥？為人民服務，耶！

⑼ mysql索引有幾種

Mysql目前主要有以下幾種索引類型：FULLTEXT，HASH，BTREE，RTREE。
那麼，這幾種索引有什麼功能和性能上的不同呢？
FULLTEXT
即為全文索引，目前只有MyISAM引擎支持。其可以在CREATE TABLE ，ALTER TABLE ，CREATE INDEX 使用，不過目前只有 CHAR、VARCHAR ，TEXT 列上可以創建全文索引。值得一提的是，在數據量較大時候，現將數據放入一個沒有全局索引的表中，然後再用CREATE INDEX創建FULLTEXT索引，要比先為一張表建立FULLTEXT然後再將數據寫入的速度快很多。
全文索引並不是和MyISAM一起誕生的，它的出現是為了解決WHERE name LIKE 「%word%"這類針對文本的模糊查詢效率較低的問題。在沒有全文索引之前，這樣一個查詢語句是要進行遍歷數據表操作的，可見，在數據量較大時是極其的耗時的，如果沒有非同步IO處理，進程將被挾持，很浪費時間，當然這里不對非同步IO作進一步講解，想了解的童鞋，自行谷哥。
全文索引的使用方法並不復雜：
創建ALTER TABLE table ADD INDEX `FULLINDEX` USING FULLTEXT(`cname1`[,cname2…]);
使用SELECT * FROM table WHERE MATCH(cname1[,cname2…]) AGAINST ('word' MODE );
其中， MODE為搜尋方式（IN BOOLEAN MODE ，IN NATURAL LANGUAGE MODE ，IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION / WITH QUERY EXPANSION）。
關於這三種搜尋方式，愚安在這里也不多做交代，簡單地說，就是，布爾模式，允許word里含一些特殊字元用於標記一些具體的要求，如+表示一定要有，-表示一定沒有，*表示通用匹配符，是不是想起了正則，類似吧；自然語言模式，就是簡單的單詞匹配；含表達式的自然語言模式，就是先用自然語言模式處理，對返回的結果，再進行表達式匹配。
對搜索引擎稍微有點了解的同學，肯定知道分詞這個概念，FULLTEXT索引也是按照分詞原理建立索引的。西文中，大部分為字母文字，分詞可以很方便的按照空格進行分割。但很明顯，中文不能按照這種方式進行分詞。那又怎麼辦呢？這個向大家介紹一個Mysql的中文分詞插件Mysqlcft，有了它，就可以對中文進行分詞，想了解的同學請移步Mysqlcft，當然還有其他的分詞插件可以使用。
HASH
Hash這個詞，可以說，自打我們開始碼的那一天起，就開始不停地見到和使用到了。其實，hash就是一種（key=>value）形式的鍵值對，如數學中的函數映射，允許多個key對應相同的value，但不允許一個key對應多個value。正是由於這個特性，hash很適合做索引，為某一列或幾列建立hash索引，就會利用這一列或幾列的值通過一定的演算法計算出一個hash值，對應一行或幾行數據（這里在概念上和函數映射有區別，不要混淆）。在java語言中，每個類都有自己的hashcode()方法，沒有顯示定義的都繼承自object類，該方法使得每一個對象都是唯一的，在進行對象間equal比較，和序列化傳輸中起到了很重要的作用。hash的生成方法有很多種，足可以保證hash碼的唯一性，例如在MongoDB中，每一個document都有系統為其生成的唯一的objectID（包含時間戳，主機散列值，進程PID，和自增ID）也是一種hash的表現。額，我好像扯遠了-_-!
由於hash索引可以一次定位，不需要像樹形索引那樣逐層查找,因此具有極高的效率。那為什麼還需要其他的樹形索引呢？
在這里愚安就不自己總結了。引用下園子里其他大神的文章：來自 14的路 的MySQL的btree索引和hash索引的區別
（1）Hash 索引僅僅能滿足"=","IN"和"<=>"查詢，不能使用范圍查詢。
由於 Hash 索引比較的是進行 Hash 運算之後的 Hash 值，所以它只能用於等值的過濾，不能用於基於范圍的過濾，因為經過相應的 Hash 演算法處理之後的 Hash 值的大小關系，並不能保證和Hash運算前完全一樣。
（2）Hash 索引無法被用來避免數據的排序操作。
由於 Hash 索引中存放的是經過 Hash 計算之後的 Hash 值，而且Hash值的大小關系並不一定和 Hash 運算前的鍵值完全一樣，所以資料庫無法利用索引的數據來避免任何排序運算；
（3）Hash 索引不能利用部分索引鍵查詢。
對於組合索引，Hash 索引在計算 Hash 值的時候是組合索引鍵合並後再一起計算 Hash 值，而不是單獨計算 Hash 值，所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候，Hash 索引也無法被利用。
（4）Hash 索引在任何時候都不能避免表掃描。
前面已經知道，Hash 索引是將索引鍵通過 Hash 運算之後，將 Hash運算結果的 Hash 值和所對應的行指針信息存放於一個 Hash 表中，由於不同索引鍵存在相同 Hash 值，所以即使取滿足某個 Hash 鍵值的數據的記錄條數，也無法從 Hash 索引中直接完成查詢，還是要通過訪問表中的實際數據進行相應的比較，並得到相應的結果。
（5）Hash 索引遇到大量Hash值相等的情況後性能並不一定就會比B-Tree索引高。
對於選擇性比較低的索引鍵，如果創建 Hash 索引，那麼將會存在大量記錄指針信息存於同一個 Hash 值相關聯。這樣要定位某一條記錄時就會非常麻煩，會浪費多次表數據的訪問，而造成整體性能低下。

愚安我稍作補充，講一下HASH索引的過程，順便解釋下上面的第4,5條：
當我們為某一列或某幾列建立hash索引時（目前就只有MEMORY引擎顯式地支持這種索引），會在硬碟上生成類似如下的文件：
hash值 存儲地址
1db54bc745a1 77#45b5
4bca452157d4 76#4556,77#45cc…
…
hash值即為通過特定演算法由指定列數據計算出來，磁碟地址即為所在數據行存儲在硬碟上的地址（也有可能是其他存儲地址，其實MEMORY會將hash表導入內存）。
這樣，當我們進行WHERE age = 18 時，會將18通過相同的演算法計算出一個hash值==>在hash表中找到對應的儲存地址==>根據存儲地址取得數據。
所以，每次查詢時都要遍歷hash表，直到找到對應的hash值，如（4），數據量大了之後，hash表也會變得龐大起來，性能下降，遍歷耗時增加，如（5）。
BTREE
BTREE索引就是一種將索引值按一定的演算法，存入一個樹形的數據結構中，相信學過數據結構的童鞋都對當初學習二叉樹這種數據結構的經歷記憶猶新，反正愚安我當時為了軟考可是被這玩意兒好好地折騰了一番，不過那次考試好像沒怎麼考這個。如二叉樹一樣，每次查詢都是從樹的入口root開始，依次遍歷node，獲取leaf。
BTREE在MyISAM里的形式和Innodb稍有不同
在 Innodb里，有兩種形態：一是primary key形態，其leaf node里存放的是數據，而且不僅存放了索引鍵的數據，還存放了其他欄位的數據。二是secondary index，其leaf node和普通的BTREE差不多，只是還存放了指向主鍵的信息.
而在MyISAM里，主鍵和其他的並沒有太大區別。不過和Innodb不太一樣的地方是在MyISAM里，leaf node里存放的不是主鍵的信息，而是指向數據文件里的對應數據行的信息.
RTREE
RTREE在mysql很少使用，僅支持geometry數據類型，支持該類型的存儲引擎只有MyISAM、BDb、InnoDb、NDb、Archive幾種。
相對於BTREE，RTREE的優勢在於范圍查找.
各種索引的使用情況
（1）對於BTREE這種Mysql默認的索引類型，具有普遍的適用性
（2）由於FULLTEXT對中文支持不是很好，在沒有插件的情況下，最好不要使用。其實，一些小的博客應用，只需要在數據採集時，為其建立關鍵字列表，通過關鍵字索引，也是一個不錯的方法，至少愚安我是經常這么做的。
（3）對於一些搜索引擎級別的應用來說，FULLTEXT同樣不是一個好的處理方法，Mysql的全文索引建立的文件還是比較大的，而且效率不是很高，即便是使用了中文分詞插件，對中文分詞支持也只是一般。真要碰到這種問題，Apache的Lucene或許是你的選擇。
（4）正是因為hash表在處理較小數據量時具有無可比擬的素的優勢，所以hash索引很適合做緩存（內存資料庫）。如mysql資料庫的內存版本Memsql，使用量很廣泛的緩存工具Mencached，NoSql資料庫redis等，都使用了hash索引這種形式。當然，不想學習這些東西的話Mysql的MEMORY引擎也是可以滿足這種需求的。
（5）至於RTREE，愚安我至今還沒有使用過，它具體怎麼樣，我就不知道了。有RTREE使用經歷的同學，到時可以交流下！

⑽ 資料庫索引的作用

為什麼要創建索引呢？這是因為，創建索引可以大大提高系統的性能。第一，通過創建唯一性索引，可以保證資料庫表中每一行數據的唯一性。第二，可以大大加快 數據的檢索速度，這也是創建索引的最主要的原因。第三，可以加速表和表之間的連接，特別是在實現數據的參考完整性方面特別有意義。第四，在使用分組和排序 子句進行數據檢索時，同樣可以顯著減少查詢中分組和排序的時間。第五，通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能。

也許會有人要問：增加索引有如此多的優點，為什麼不對表中的每一個列創建一個索引呢？這種想法固然有其合理性，然而也有其片面性。雖然，索引有許多優點， 但是，為表中的每一個列都增加索引，是非常不明智的。這是因為，增加索引也有許多不利的一個方面。第一，創建索引和維護索引要耗費時間，這種時間隨著數據 量的增加而增加。第二，索引需要佔物理空間，除了數據表占數據空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。 第三，當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。

索引是建立在資料庫表中的某些列的上面。因此，在創建索引的時候，應該仔細考慮在哪些列上可以創建索引，在哪些列上不能創建索引。一般來說，應該在這些列 上創建索引，例如：在經常需要搜索的列上，可以加快搜索的速度；在作為主鍵的列上，強制該列的唯一性和組織表中數據的排列結構；在經常用在連接的列上，這 些列主要是一些外鍵，可以加快連接的速度；在經常需要根據范圍進行搜索的列上創建索引，因為索引已經排序，其指定的范圍是連續的；在經常需要排序的列上創 建索引，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；在經常使用在WHERE子句中的列上面創建索引，加快條件的判斷速度。

同樣，對於有些列不應該創建索引。一般來說，不應該創建索引的的這些列具有下列特點：第一，對於那些在查詢中很少使用或者參考的列不應該創建索引。這是因 為，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。第二，對於那 些只有很少數據值的列也不應該增加索引。這是因為，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比 例，即需要在表中搜索的數據行的比例很大。增加索引，並不能明顯加快檢索速度。第三，對於那些定義為text, image和bit數據類型的列不應該增加索引。這是因為，這些列的數據量要麼相當大，要麼取值很少。第四，當修改性能遠遠大於檢索性能時，不應該創建索 引。這是因為，修改性能和檢索性能是互相矛盾的。當增加索引時，會提高檢索性能，但是會降低修改性能。當減少索引時，會提高修改性能，降低檢索性能。因 此，當修改性能遠遠大於檢索性能時，不應該創建索引。

創建索引的方法和索引的特徵
創建索引的方法 51aspx.com
創建索引有多種方法，這些方法包括直接創建索引的方法和間接創建索引的方法。直接創建索引，例如使用CREATE INDEX語句或者使用創建索引向導，間接創建索引，例如在表中定義主鍵約束或者唯一性鍵約束時，同時也創建了索引。雖然，這兩種方法都可以創建索引，但 是，它們創建索引的具體內容是有區別的。
使用CREATE INDEX語句或者使用創建索引向導來創建索引，這是最基本的索引創建方式，並且這種方法最具有柔性，可以定製創建出符合自己需要的索引。在使用這種方式 創建索引時，可以使用許多選項，例如指定數據頁的充滿度、進行排序、整理統計信息等，這樣可以優化索引。使用這種方法，可以指定索引的類型、唯一性和復合 性，也就是說，既可以創建聚簇索引，也可以創建非聚簇索引，既可以在一個列上創建索引，也可以在兩個或者兩個以上的列上創建索引。

通過定義主鍵約束或者唯一性鍵約束，也可以間接創建索引。主鍵約束是一種保持數據完整性的邏輯，它限製表中的記錄有相同的主鍵記錄。在創建主鍵約束時，系 統自動創建了一個唯一性的聚簇索引。雖然，在邏輯上，主鍵約束是一種重要的結構，但是，在物理結構上，與主鍵約束相對應的結構是唯一性的聚簇索引。換句話 說，在物理實現上，不存在主鍵約束，而只存在唯一性的聚簇索引。同樣，在創建唯一性鍵約束時，也同時創建了索引，這種索引則是唯一性的非聚簇索引。因此， 當使用約束創建索引時，索引的類型和特徵基本上都已經確定了，由用戶定製的餘地比較小。

當在表上定義主鍵或者唯一性鍵約束時，如果表中已經有了使用CREATE INDEX語句創建的標准索引時，那麼主鍵約束或者唯一性鍵約束創建的索引覆蓋以前創建的標准索引。也就是說，主鍵約束或者唯一性鍵約束創建的索引的優先 級高於使用CREATE INDEX語句創建的索引。

索引的特徵
索引有兩個特徵，即唯一性索引和復合索引。
唯一性索引保證在索引列中的全部數據是唯一的，不會包含冗餘數據。如果表中已經有一個主鍵約束或者唯一性鍵約束，那麼當創建表或者修改表時，SQL Server自動創建一個唯一性索引。然而，如果必須保證唯一性，那麼應該創建主鍵約束或者唯一性鍵約束，而不是創建一個唯一性索引。當創建唯一性索引 時，應該認真考慮這些規則：當在表中創建主鍵約束或者唯一性鍵約束時，SQL Server自動創建一個唯一性索引；如果表中已經包含有數據，那麼當創建索引時，SQL Server檢查表中已有數據的冗餘性；每當使用插入語句插入數據或者使用修改語句修改數據時，SQL Server檢查數據的冗餘性：如果有冗餘值，那麼SQL Server取消該語句的執行，並且返回一個錯誤消息；確保表中的每一行數據都有一個唯一值，這樣可以確保每一個實體都可以唯一確認；只能在可以保證實體 完整性的列上創建唯一性索引，例如，不能在人事表中的姓名列上創建唯一性索引，因為人們可以有相同的姓名。

復合索引就是一個索引創建在兩個列或者多個列上。在搜索時，當兩個或者多個列作為一個關鍵值時，最好在這些列上創建復合索引。當創建復合索引時，應該考慮 這些規則：最多可以把16個列合並成一個單獨的復合索引，構成復合索引的列的總長度不能超過900位元組，也就是說復合列的長度不能太長；在復合索引中，所 有的列必須來自同一個表中，不能跨表建立復合列；在復合索引中，列的排列順序是非常重要的，因此要認真排列列的順序，原則上，應該首先定義最唯一的列，例 如在（COL1，COL2）上的索引與在（COL2，COL1）上的索引是不相同的，因為兩個索引的列的順序不同；為了使查詢優化器使用復合索引，查詢語 句中的WHERE子句必須參考復合索引中第一個列；當表中有多個關鍵列時，復合索引是非常有用的；使用復合索引可以提高查詢性能，減少在一個表中所創建的 索引數量。

索引的類型
根據索引的順序與數據表的物理順序是否相同，可以把索引分成兩種類型。一種是數據表的物理順序與索引順序相同的聚簇索引，另一種是數據表的物理順序與索引順序不相同的非聚簇索引。

聚簇索引的體系結構
索引的結構類似於樹狀結構，樹的頂部稱為葉級，樹的其它部分稱為非葉級，樹的根部在非葉級中。同樣，在聚簇索引中，聚簇索引的葉級和非葉級構成了一個樹狀 結構，索引的最低級是葉級。在聚簇索引中，表中的數據所在的數據頁是葉級，在葉級之上的索引頁是非葉級，索引數據所在的索引頁是非葉級。在聚簇索引中，數 據值的順序總是按照升序排列。

應該在表中經常搜索的列或者按照順序訪問的列上創建聚簇索引。當創建聚簇索引時，應該考慮這些因素：每一個表只能有一個聚簇索引，因為表中數據的物理順序 只能有一個；表中行的物理順序和索引中行的物理順序是相同的，在創建任何非聚簇索引之前創建聚簇索引，這是因為聚簇索引改變了表中行的物理順序，數據行按 照一定的順序排列，並且自動維護這個順序；關鍵值的唯一性要麼使用UNIQUE關鍵字明確維護，要麼由一個內部的唯一標識符明確維護，這些唯一性標識符是 系統自己使用的，用戶不能訪問；聚簇索引的平均大小大約是數據表的百分之五，但是，實際的聚簇索引的大小常常根據索引列的大小變化而變化；在索引的創建過 程中，SQL Server臨時使用當前資料庫的磁碟空間，當創建聚簇索引時，需要1.2倍的表空間的大小，因此，一定要保證有足夠的空間來創建聚簇索引。

當系統訪問表中的數據時，首先確定在相應的列上是否存在有索引和該索引是否對要檢索的數據有意義。如果索引存在並且該索引非常有意義，那麼系統使用該索引 訪問表中的記錄。系統從索引開始瀏覽到數據，索引瀏覽則從樹狀索引的根部開始。從根部開始，搜索值與每一個關鍵值相比較，確定搜索值是否大於或者等於關鍵 值。這一步重復進行，直到碰上一個比搜索值大的關鍵值，或者該搜索值大於或者等於索引頁上所有的關鍵值為止。

非聚簇索引的體系結構
非聚簇索引的結構也是樹狀結構，與聚簇索引的結構非常類似，但是也有明顯的不同。
在非聚簇索引中，葉級僅包含關鍵值，而沒有包含數據行。非聚簇索引表示行的邏輯順序。 非聚簇索引有兩種體系結構：一種體系結構是在沒有聚簇索引的表上創建非聚簇索引，另一種體系結構是在有聚簇索引的表上創建非聚簇索引。

如果一個數據表中沒有聚簇索引，那麼這個數據表也稱為數據堆。當非聚簇索引在數據堆的頂部創建時，系統使用索引頁中的行標識符指向數據頁中的記錄。行標識 符存儲了數據所在位置的信息。數據堆是通過使用索引分配圖（IAM）頁來維護的。IAM頁包含了數據堆所在簇的存儲信息。在系統表sysindexes 中，有一個指針指向了與數據堆相關的第一個IAM頁。系統使用IAM頁在數據堆中瀏覽和尋找可以插入新的記錄行的空間。這些數據頁和在這些數據頁中的記錄 沒有任何的順序並且也沒有鏈接在一起。在這些數據頁之間的唯一的連接是IAM中記錄的順序。當在數據堆上創建了非聚簇索引時，葉級中包含了指向數據頁的行 標識符。行標識符指定記錄行的邏輯順序，由文件ID、頁號和行ID組成。這些行的標識符維持唯一性。非聚簇索引的葉級頁的順序不同於表中數據的物理順序。 這些關鍵值在葉級中以升序維持。

當非聚簇索引創建在有聚簇索引的表上的時候，系統使用索引頁中的指向聚簇索引的聚簇鍵。聚簇鍵存儲了數據的位置信息。如果某一個表有聚簇索引，那麼非聚簇 索引的葉級包含了映射到聚簇鍵的聚簇鍵值，而不是映射到物理的行標識符。當系統訪問有非聚簇索引的表中數據時，並且這種非聚簇索引創建在聚簇索引上，那麼 它首先從非聚簇索引來找到指向聚簇索引的指針，然後通過使用聚簇索引來找到數據。
當需要以多種方式檢索數據時，非聚簇索引是非常有用的。當創建非聚簇索引時，要考慮這些情況：在預設情況下，所創建的索引是非聚簇索引；在每一個表上面，可以創建不多於249個非聚簇索引，而聚簇索引最多隻能有一個。
系統如何訪問表中的數據
一般地，系統訪問資料庫中的數據，可以使用兩種方法：表掃描和索引查找。第一種方法是表掃描，就是指系統將指針放置在該表的表頭數據所在的數據頁上，然後 按照數據頁的排列順序，一頁一頁地從前向後掃描該表數據所佔有的全部數據頁，直至掃描完表中的全部記錄。在掃描時，如果找到符合查詢條件的記錄，那麼就將 這條記錄挑選出來。最後，將全部挑選出來符合查詢語句條件的記錄顯示出來。第二種方法是使用索引查找。索引是一種樹狀結構，其中存儲了關鍵字和指向包含關 鍵字所在記錄的數據頁的指針。當使用索引查找時，系統沿著索引的樹狀結構，根據索引中關鍵字和指針，找到符合查詢條件的的記錄。最後，將全部查找到的符合 查詢語句條件的記錄顯示出來。
在SQL Server中，當訪問資料庫中的數據時，由SQL Server確定該表中是否有索引存在。如果沒有索引，那麼SQL Server使用表掃描的方法訪問資料庫中的數據。查詢處理器根據分布的統計信息生成該查詢語句的優化執行規劃，以提高訪問數據的效率為目標，確定是使用 表掃描還是使用索引。
索引的選項
在創建索引時，可以指定一些選項，通過使用這些選項，可以優化索引的性能。這些選項包括FILLFACTOR選項、PAD_INDEX選項和SORTED_DATA_REORG選項。
使用FILLFACTOR選項，可以優化插入語句和修改語句的性能。當某個索引頁變滿時，SQL Server必須花費時間分解該頁，以便為新的記錄行騰出空間。使用FILLFACTOR選項，就是在葉級索引頁上分配一定百分比的自由空間，以便減少頁 的分解時間。當在有數據的表中創建索引時，可以使用FILLFACTOR選項指定每一個葉級索引節點的填充的百分比。預設值是0，該數值等價於100。在 創建索引的時候，內部索引節點總是留有了一定的空間，這個空間足夠容納一個或者兩個表中的記錄。在沒有數據的表中，當創建索引的時候，不要使用該選項，因 為這時該選項是沒有實際意義的。另外，該選項的數值在創建時指定以後，不能動態地得到維護，因此，只應該在有數據的表中創建索引時才使用。
PAD_INDEX選項將FILLFACTOR選項的數值同樣也用於內部的索引節點，使內部的索引節點的填充度與葉級索引的節點中的填充度相同。如果沒有 指定FILLFACTOR選項，那麼單獨指定PAD_INDEX選項是沒有實際意義的，這是因為PAD_INDEX選項的取值是由FILLFACTOR選 項的取值確定的。
當創建聚簇索引時，SORTED_DATA_REORG選項清除排序，因此可以減少建立聚簇索引所需要的時間。當在一個已經變成碎塊的表上創建或者重建聚 簇索引時，使用SORTED_DATA_REORG選項可以壓縮數據頁。當重新需要在索引上應用填充度時，也使用該選項。當使用 SORTED_DATA_REORG選項時，應該考慮這些因素：SQL Server確認每一個關鍵值是否比前一個關鍵值高，如果都不高，那麼不能創建索引；SQL Server要求1.2倍的表空間來物理地重新組織數據；使用SORTED_DATA_REORG選項，通過清除排序進程而加快索引創建進程；從表中物理 地拷貝數據；當某一個行被刪除時，其所佔的空間可以重新利用；創建全部非聚簇索引；如果希望把葉級頁填充到一定的百分比，可以同時使用 FILLFACTOR選項和SORTED_DATA_REORG選項。
索引的維護
為了維護系統性能，索引在創建之後，由於頻繁地對數據進行增加、刪除、修改等操作使得索引頁發生碎塊，因此，必須對索引進行維護。
使用DBCC SHOWCONTIG語句，可以顯示表的數據和索引的碎塊信息。當執行DBCC SHOWCONTIG語句時，SQL Server瀏覽葉級上的整個索引頁，來確定表或者指定的索引是否嚴重碎塊。DBCC SHOWCONTIG語句還能確定數據頁和索引頁是否已經滿了。當對表進行大量的修改或者增加大量的數據之後，或者表的查詢非常慢時，應該在這些表上執行 DBCC SHOWCONTIG語句。當執行DBCC SHOWCONTIG語句時，應該考慮這些因素：當執行DBCC SHOWCONTIG語句時，SQL Server要求指定表的ID號或者索引的ID號，表的ID號或者索引的ID號可以從系統表sysindexes中得到；應該確定多長時間使用一次 DBCC SHOWCONTIG語句，這個時間長度要根據表的活動情況來定，每天、每周或者每月都可以。
使用DBCC DBREINDEX語句重建表的一個或者多個索引。當希望重建索引和當表上有主鍵約束或者唯一性鍵約束時，執行DBCC DBREINDEX語句。除此之外，執行DBCC DBREINDEX語句還可以重新組織葉級索引頁的存儲空間、刪除碎塊和重新計算索引統計。當使用執行DBCC DBREINDEX語句時，應該考慮這些因素：根據指定的填充度，系統重新填充每一個葉級頁；使用DBCC DBREINDEX語句重建主鍵約束或者唯一性鍵約束的索引；使用SORTED_DATA_REORG選項可以更快地創建聚簇索引，如果沒有排列關鍵值， 那麼不能使用DBCC DBREINDEX語句；DBCC DBREINDEX語句不支持系統表。另外，還可以使用資料庫維護規劃向導自動地進行重建索引的進程。
統計信息是存儲在SQL Server中的列數據的樣本。這些數據一般地用於索引列，但是還可以為非索引列創建統計。SQL Server維護某一個索引關鍵值的分布統計信息，並且使用這些統計信息來確定在查詢進程中哪一個索引是有用的。查詢的優化依賴於這些統計信息的分布准確 度。查詢優化器使用這些數據樣本來決定是使用表掃描還是使用索引。當表中數據發生變化時，SQL Server周期性地自動修改統計信息。索引統計被自動地修改，索引中的關鍵值顯著變化。統計信息修改的頻率由索引中的數據量和數據改變數確定。例如，如 果表中有10000行數據，1000行數據修改了，那麼統計信息可能需要修改。然而，如果只有50行記錄修改了，那麼仍然保持當前的統計信息。除了系統自 動修改之外，用戶還可以通過執行UPDATE STATISTICS語句或者sp_updatestats系統存儲過程來手工修改統計信息。使用UPDATE STATISTICS語句既可以修改表中的全部索引，也可以修改指定的索引。
使用SHOWPLAN和STATISTICS IO語句可以分析索引和查詢性能。使用這些語句可以更好地調整查詢和索引。SHOWPLAN語句顯示在連接表中使用的查詢優化器的每一步以及表明使用哪一 個索引訪問數據。使用SHOWPLAN語句可以查看指定查詢的查詢規劃。當使用SHOWPLAN語句時，應該考慮這些因素。SET SHOWPLAN_ALL語句返回的輸出結果比SET SHOWPLAN_TEXT語句返回的輸出結果詳細。然而，應用程序必須能夠處理SET SHOWPLAN_ALL語句返回的輸出結果。SHOWPLAN語句生成的信息只能針對一個會話。如果重新連接SQL Server，那麼必須重新執行SHOWPLAN語句。STATISTICS IO語句表明輸入輸出的數量，這些輸入輸出用來返回結果集和顯示指定查詢的邏輯的和物理的I/O的信息。可以使用這些信息來確定是否應該重寫查詢語句或者 重新設計索引。使用STATISTICS IO語句可以查看用來處理指定查詢的I/O信息。
就象SHOWPLAN語句一樣，優化器隱藏也用來調整查詢性能。優化器隱藏可以對查詢性能提供較小的改進，並且如果索引策略發生了改變，那麼這種優化器隱 藏就毫無用處了。因此，限制使用優化器隱藏，這是因為優化器隱藏更有效率和更有柔性。當使用優化器隱藏時，考慮這些規則：指定索引名稱、當 index_id為0時為使用表掃描、當index_id為1時為使用聚簇索引；優化器隱藏覆蓋查詢優化器，如果數據或者環境發生了變化，那麼必須修改優 化器隱藏。
索引調整向導
索引調整向導是一種工具，可以分析一系列資料庫的查詢語句，提供使用一系列資料庫索引的建議，優化整個查詢語句的性能。對於查詢語句，需要指定下列內容：
查詢語句，這是將要優化的工作量
包含了這些表的資料庫，在這些表中，可以創建索引，提高查詢性能
在分析中使用的表
在分析中，考慮的約束條件，例如索引可以使用的最大磁碟空間
這里指的工作量，可以來自兩個方面：使用SQL Server捕捉的軌跡和包含了SQL語句的文件。索引調整向導總是基於一個已經定義好的工作量。如果一個工作量不能反映正常的操作，那麼它建議使用的索 引不是實際的工作量上性能最好的索引。索引調整向導調用查詢分析器，使用所有可能的組合評定在這個工作量中每一個查詢語句的性能。然後，建議在整個工作量 上可以提高整個查詢語句的性能的索引。如果沒有供索引調整向導來分析的工作量，那麼可以使用圖解器立即創建它。一旦決定跟蹤一條正常資料庫活動的描述樣 本，向導能夠分析這種工作量和推薦能夠提高資料庫工作性能的索引配置。
索引調整向導對工作量進行分析之後，可以查看到一系列的報告，還可以使該向導立即創建所建議的最佳索引，或者使這項工作成為一種可以調度的作業，或者生成一個包含創建這些索引的SQL語句的文件。
索引調整向導允許為SQL Server資料庫選擇和創建一種理想的索引組合和統計，而不要求對資料庫結構、工作量或者SQL Server內部達到專家的理解程度。總之，索引調整向導能夠作到以下幾個方面的工作：
通過使用查詢優化器來分析工作量中的查詢任務，向有大量工作量的資料庫推薦一種最佳的索引混合方式
分析按照建議作出改變之後的效果，包括索引的用法、表間查詢的分布和大量工作中查詢的工作效果
為少量查詢任務推薦調整資料庫的方法
通過設定高級選項如磁碟空間約束、最大的查詢語句數量和每個索引的最多列的數量等，允許定製推薦方式
圖解器
圖解器能夠實時抓取在伺服器中運行的連續圖片，可以選取希望監測的項目和事件，包括Transact-SQL語句和批命令、對象的用法、鎖定、安全事件和 錯誤。圖解器能夠過濾這些事件，僅僅顯示用戶關心的問題。可以使用同一台伺服器或者其他伺服器重復已經記錄的跟蹤事件，重新執行那些已經作了記錄的命令。 通過集中處理這些事件，就能夠很容易監測和調試SQL Server中出現的問題。通過對特定事件的研究，監測和調試SQL Server問題變得簡單多了。
查詢處理器
查詢處理器是一種可以完成許多工作的多用途的工具。在查詢處理器中，可以互動式地輸入和執行各種Transact-SQL語句，並且在一個窗口中可以同時 查看Transact-SQL語句和其結果集；可以在查詢處理器中同時執行多個Transact-SQL語句，也可以執行腳本文件中的部分語句；提供了一 種圖形化分析查詢語句執行規劃的方法，可以報告由查詢處理器選擇的數據檢索方法，並且可以根據查詢規劃調整查詢語句的執行，提出執行可以提高性能的優化索 引建議，這種建議只是針對一條查詢語句的索引建議，只能提高這一條查詢語句的查詢性能。
系統為每一個索引創建一個分布頁，統計信息就是指存儲在分布頁上的某一個表中的一個或者多個索引的關鍵值的分布信息。當執行查詢語句時，為了提高查詢速度 和性能，系統可以使用這些分布信息來確定使用表的哪一個索引。查詢處理器就是依賴於這些分布的統計信息，來生成查詢語句的執行規劃。執行規劃的優化程度依 賴於這些分布統計信息的准確步驟的高低程度。如果這些分布的統計信息與索引的物理信息非常一致，那麼查詢處理器可以生成優化程度很高的執行規劃。相反，如 果這些統計信息與索引的實際存儲的信息相差比較大，那麼查詢處理器生成的執行規劃的優化程度則比較低。
查詢處理器從統計信息中提取索引關鍵字的分布信息，除了用戶可以手工執行UPDATE STATISTICS之外，查詢處理器還可以自動收集統計這些分布信息。這樣，就能夠充分保證查詢處理器使用最新的統計信息，保證執行規劃具有很高的優化 程度，減少了維護的需要。當然，使用查詢處理器生成的執行規劃，也有一些限制。例如，使用執行規劃只能提高單個查詢語句的性能，但是可能對整個系統的性能 產生正面的或者付面的影響，因此，要想提高整個系統的查詢性能，應該使用索引調整向導這樣的工具。
結論
在以前的SQL Server版本中，在一個查詢語句中，一個表上最多使用一個索引。而在SQL Server 7.0中，索引操作得到了增強。SQL Server現在使用索引插入和索引聯合演算法來實現在一個查詢語句中的可以使用多個索引。共享的行標識符用於連接同一個表上的兩個索引。如果某個表中有一 個聚簇索引，因此有一個聚簇鍵，那麼該表上的全部非聚簇索引的葉節點使用該聚簇鍵作為行定位器，而不是使用物理記錄標識符。如果表中沒有聚簇索引，那麼非 聚簇索引繼續使用物理記錄標識符指向數據頁。在上面的兩種情況中，行定位器是非常穩定的。當聚簇索引的葉節點分開時，由於行定位器是有效的，所以非聚簇索 引不需要被修改。如果表中沒有聚簇索引，那麼頁的分開就不會發生。而在以前的版本中，非聚簇索引使用物理記錄標識符如頁號和行號，作為行的定位器。例如， 如果聚簇索引（數據頁）發生分解時，許多記錄行被移動到了一個新的數據頁，因此有了多個新的物理記錄標識符。那麼，所有的非聚簇索引都必須使用這些新的物 理記錄標識符進行修改，這樣就需要耗費大量的時間和資源。
索引調整向導無論對熟練用戶還是新用戶，都是一個很好的工具。熟練用戶可以使用該向導創建一個基本的索引配置，然後在基本的索引配置上面進行調整和定製。新用戶可以使用該向導快速地創建優化的索引。
參考: