蛋疼的郁悶——聚集索引掃描、非聚集索引掃描、表掃描區(qū)別
聚集索引掃描,首先我們知道數(shù)據(jù)它是以索引鍵為葉節(jié)點排列起來的樹形數(shù)據(jù)結(jié)構(gòu),表中每行的數(shù)據(jù)都附屬在索引鍵中,對這樣的表進行數(shù)據(jù)查找時,最快的方式當然是“聚集索引查找”。什么情況下才是“聚集索引掃描”呢?是當你要查找的數(shù)據(jù)的條件字段上沒有索引時,此時查詢執(zhí)行器將對整個表中的數(shù)據(jù)挨個的進行讀取確認符合查詢條件的數(shù)據(jù),但當該表上有字段設(shè)有聚集索引時,該掃描過程稱之為“聚集索引掃描",相反的情況是當該表上沒有一個字段設(shè)有”聚集索引“時,該掃描過程稱之為”表掃描“。其實他們本質(zhì)上的過程都是一樣的,就是挨個的獲取表中每一行的數(shù)據(jù),確認滿足符合條件的數(shù)據(jù)的過程。從性能上看也幾乎是一樣的。
表掃描,表中的數(shù)據(jù)是以”堆“的形式存放起來的,也就是該表在插入一條新數(shù)據(jù)時,不用考慮這條新數(shù)據(jù)應該邏輯上放在哪個位置,只需知道它前一條數(shù)據(jù)的位置,放在它的后面即可,這里要注意一點,就是大家千萬不要以為以聚集索引存放的數(shù)據(jù)在物理磁盤上也是順序存放的喲!它們以塊的方式存放在磁盤上的隨機位置,只是使用鏈表的方式通過指針指示其前驅(qū)和后繼節(jié)點的位置。這其中的道理,大家悟悟吧!原因很簡單,假設(shè)聚集索引表在磁盤上數(shù)據(jù)存放是先后聚集在一起的,那么當一條中間節(jié)點的數(shù)據(jù)插入到一個靠前的位置時,那么豈不是要移動幾萬或是幾億的數(shù)據(jù)向磁盤的后位置去。那是太可怕了。
我們對于聚集索引掃描和表掃描比較容易理解的,但是對于非聚集索引掃描不太容易理解,這一點也往往容易使初學者感到很是困惑,原因是總認為沒必要存在非聚集索引掃描,因為如果查詢結(jié)果不具有高選擇性的話,在聚集索引表中可以使用聚集索引掃描,在對表中會使用表掃描的,那么為什么要會存在非聚集索引掃描呢?
之所以有這樣的問題,是因為我們沒有考慮到一種情況,那就是查詢結(jié)果如果被建有非聚集索引的字段覆蓋或包含了,而此時where條件字段上的非聚集索引對于本次查詢結(jié)果又不具有高選擇性,那么你說查詢優(yōu)化器會選擇怎樣的查詢計劃呢?1、非聚集索引查找?這肯定不行,因為結(jié)果集不具有高選擇性。2、聚集索引掃描(或表掃描)?答案也不是,因為前兩者開銷還是比較大的。我們的優(yōu)化器何不選擇該非聚集索引呢?只要對該該索引執(zhí)行一次掃描,那么查詢根本不用訪問數(shù)據(jù)頁,因為查詢結(jié)果字段都被該索引覆蓋或包含了,這個代價可比前兩者小多了。
哈哈!


浙公網(wǎng)安備 33010602011771號