其實對于非專業(yè)的 數(shù)據(jù)庫 操作人員來講,例如軟件開發(fā)人員,在很大程度上都搞不清楚數(shù)據(jù)庫索引的一些基本知識,有些是知其一不知其二,或者是知其然不知其所以然。造成這種情況的主要原因我覺的是行業(yè)原因,有很多公司都有自己的DBA團隊,他們會幫助你優(yōu)化 SQL ,開發(fā)人員即使不懂優(yōu)化問題也不大,所以開發(fā)人員對這方面也就不會下太多功夫去了解SQL優(yōu)化,但如果公司沒有這樣的DBA呢,就只能靠程序員自己了。 最近突然想起前一陣和一朋友的聊天,當(dāng)時他問我的問題是一個非常普通的問題: 說說SQL聚集索引和非聚集索引的區(qū)別。
大家可能認為這個問題難度不大,認為太熟悉了,也許不會感興趣,但你真能說清楚嗎?其實要想說明白這兩者的差別也不是三兩句就說的清的,那天我也是覺的這問題太泛了,就隨便說了其中的兩個區(qū)別:
1、聚集索引一個表只能有一個,而非聚集索引一個表可以存在多個,這個跟沒問題沒差別,一般人都知道。
2、聚集索引存儲記錄是物理上連續(xù)存在,而非聚集索引是邏輯上的連續(xù),物理存儲并不連續(xù),這個大家也都知道。
上面的兩點從大的方面講都是講的通的,后面我們繼續(xù)探討,舉一個實際點的例子,一個學(xué)生表student,里面是學(xué)生號id,學(xué)生姓名,學(xué)生所在城市ID,學(xué)生成績(總分)。
問:如果想按姓名查詢,如何做優(yōu)化?
答:在姓名字段上建立索引。
問:建立什么類型的索引?
答:建立非聚集索引。
問:為什么?
答:一般有范圍查詢的需求,可以考慮在此字段上創(chuàng)建聚集索引。
問:學(xué)分有重復(fù)性,在學(xué)分字段上創(chuàng)建聚集索引能行嗎?
....沉思,不能創(chuàng)建嗎?之前的項目好像真這樣做過,答:應(yīng)該可以吧。
問:聚集索引的約束是什么?
答:唯一性啊?
問:既然是唯一性,那么學(xué)分字段上還能創(chuàng)建聚集索引嗎?
....再次沉思,應(yīng)該可以啊,但索引的約束又怎么說呢?答:應(yīng)該可以的,以前用過。
我自認為是對數(shù)據(jù)庫索引知識有一定研究的,但可能是有兩年沒實際接觸SQL的原因,一時還真想不出具有說服力的解釋,朋友們看到這能解答我的問題嗎?
其實上面的我們需要搞清楚以下幾個問題:
第一:聚集索引的約束是唯一性,是否要求字段也是唯一的呢?
分析:如果認為是的朋友,可能是受系統(tǒng)默認設(shè)置的影響,一般我們指定一個表的主鍵,如果這個表之前沒有聚集索引,同時建立主鍵時候沒有強制指定使用非聚集索引,SQL會默認在此字段上創(chuàng)建一個聚集索引,而主鍵都是唯一的,所以理所當(dāng)然的認為創(chuàng)建聚集索引的字段也需要唯一。
結(jié)論:聚集索引可以創(chuàng)建在任何一列你想創(chuàng)建的字段上,這是從理論上講,實際情況并不能隨便指定,否則在性能上會是惡夢。
第二:為什么聚集索引可以創(chuàng)建在任何一列上,如果此表沒有主鍵約束,即有可能存在重復(fù)行數(shù)據(jù)呢?
粗一看,這還真是和聚集索引的約束相背,但實際情況真可以創(chuàng)建聚集索引。
分析其原因是:如果未使用 UNIQUE 屬性創(chuàng)建聚集索引,數(shù)據(jù)庫引擎將向表自動添加一個四字節(jié) uniqueifier 列。必要時,數(shù)據(jù)庫引擎 將向行自動添加一個 uniqueifier 值,使每個鍵唯一。此列和列值供內(nèi)部使用,用戶不能查看或訪問。
第三:是不是聚集索引就一定要比非聚集索引性能優(yōu)呢?
如果想查詢學(xué)分在60-90之間的學(xué)生的學(xué)分以及姓名,在學(xué)分上創(chuàng)建聚集索引是否是最優(yōu)的呢?
答:否。既然只輸出兩列,我們可以在學(xué)分以及學(xué)生姓名上創(chuàng)建聯(lián)合非聚集索引,此時的索引就形成了覆蓋索引,即索引所存儲的內(nèi)容就是最終輸出的數(shù)據(jù),這種索引在比以學(xué)分為聚集索引做查詢性能更好。
第四:在數(shù)據(jù)庫中通過什么描述聚集索引與非聚集索引的?
索引是通過二叉樹的形式進行描述的,我們可以這樣區(qū)分聚集與非聚集索引的區(qū)別:聚集索引的葉節(jié)點就是最終的數(shù)據(jù)節(jié)點,而非聚集索引的葉節(jié)仍然是索引節(jié)點,但它有一個指向最終數(shù)據(jù)的指針。
第五:在主鍵是創(chuàng)建聚集索引的表在數(shù)據(jù)插入上為什么比主鍵上創(chuàng)建非聚集索引表速度要慢?
有了上面第四點的認識,我們分析這個問題就有把握了,在有主鍵的表中插入數(shù)據(jù)行,由于有主鍵唯一性的約束,所以需要保證插入的數(shù)據(jù)沒有重復(fù)。我們來比較下主鍵為聚集索引和非聚集索引的查找情況:聚集索引由于索引葉節(jié)點就是數(shù)據(jù)頁,所以如果想檢查主鍵的唯一性,需要遍歷所有數(shù)據(jù)節(jié)點才行,但非聚集索引不同,由于非聚集索引上已經(jīng)包含了主鍵值,所以查找主鍵唯一性,只需要遍歷所有的索引頁就行,這比遍歷所有數(shù)據(jù)行減少了不少IO消耗。這就是為什么主鍵上創(chuàng)建非聚集索引比主鍵上創(chuàng)建聚集索引在插入數(shù)據(jù)時要快的真正原因。
好了,講這這些,不知道大家是否真的了解SQL的聚焦索引,我也是數(shù)據(jù)庫新手(從使用時間上來講也不算新了,哈哈),不專業(yè),有什么不對的地方,希望大家批評指正,下篇我會分析一些數(shù)據(jù)庫訪問索引的情況,有圖的情況下,也許看的更加明白。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
