■金瀾
MySQL查詢過程的瓶頸在于磁盤IO,那怎么降低磁盤IO次數呢?答案就是索引。
正確的使用索引,就能有效地把磁盤IO的次數降到常數級,這樣查詢速度將會變得非???。
在磁盤中,MySQL存放數據的基本單位是數據頁,數據是放在數據頁中的,每個數據頁中都有很多的數據行。在數據頁的數據區(qū)中存放著很多數據行,這些數據行就對應數據表中的一行行數據,它們都是通過單向鏈表方式連接組合起來的。而多個數據頁之間又是通過雙向鏈表的方式連接起來的。
一個數據頁的大小默認為16 KB,16 KB的大小肯定是不可能放得下一整張表的數據的,所以MySQL表中的數據,比如訂單表中的訂單數據,會通過這樣雙向鏈表的結構放在多個數據頁中。
如果要查詢一條數據,就要沿著雙向鏈表一個個去尋找。比如,要查詢主鍵為1的那條數據,可從數據頁1開始查詢。
首先,將數據頁1從磁盤中加載到MySQL內存中,如果發(fā)現數據頁1中沒有想要的那條數據,就要沿著雙向鏈表一直尋找下去。
最糟糕的情況就是沿著數據頁1、數據頁2、一直到最后,在最后一個數據頁中才找到想要的那條數據,但在這之前,我們得要把數據頁1一直到數據頁100,將這100個數據頁通過磁盤IO加載到內存中,相當于是全表掃描。
就算MySQL中有預讀機制存在,可能會預先發(fā)生幾次磁盤IO,提前加載一些數據頁到內存中,但這100個數據頁至少會導致幾十次磁盤IO,而磁盤IO這個過程很耗費性能。
MySQL的索引是如何形成的呢?
那有沒有什么辦法,能夠讓我們盡量快定位到數據頁,而不至于全表掃描呢?
順著數據頁的雙向鏈表數據結構一個個去尋找,未免顯得太費力了,我們可以為每個數據頁創(chuàng)建一個目錄,查詢數據時,先到目錄里看一下有沒有自己想要的數據,這樣不就快很多了嗎。
比如,以數據頁1舉例,數據頁1中有很多的數據行,數據行之間都是用指針連接,并且以單向鏈表的方式組織起來的,并且單向鏈表中主鍵一定是有序的,無序的數據是沒法創(chuàng)建索引的。
數據行前面的0、2、3表示記錄的類型,也就是數據行的類型,0表示普通類型,就是表中的一行普通數據,2表示最小記錄,3表示最大記錄,因為數據行對應的主鍵都是有順序的。這里為了方便展示索引,假設每個數據頁中都有20條數據,當我們建立索引之后,可以看到,索引頁中會記錄每個數據頁中最小的主鍵即ID的值,以及對應的數據頁號,而索引頁就發(fā)揮了數據頁目錄的效果。
索引頁其實也是數據頁,只不過是我們拿來專門存放數據頁的目錄信息而已。索引頁中的記錄類型,除了2和3之外還有1,1表示的是目錄的類型,因為它是指向具體的某個數據頁。
而如果數據頁很多的話,一個索引頁中肯定就放不下,此時,MySQL會把超出索引頁的目錄信息放到新的索引頁中,然后向上再擴展出一個索引頁。這時數據頁3和數據頁4的目錄信息,被放到了索引頁2中,然后索引3作為擴展出來的索引頁,記錄索引頁1和索引頁2中的最小主鍵值以及索引頁號,也就是說索引頁3中記錄的信息,就相當于更上一層索引的目錄信息了。
如果索引頁3中的容量也不夠了,這個時候,同樣會把超出索引頁3的信息,放到新的一個同層級的索引頁中,然后再向上擴展一層。在索引頁3中的信息放不下之后,就會放到索引頁4中,然后向上再拓展一層索引5,索引5中存放的就是索引3和索引4的目錄信息,規(guī)律都是一樣的。
索引頁逐層的往上擴展,看起來就像一棵樹一樣,這也就是我們經常說的B+索引樹,3層索引一般就可以存放千萬級別的數據了。
有了索引之后,如果要查詢主鍵為1的那條數據,就可以從B+索引樹最上面的那個索引頁開始查詢??梢园阉饕?先加載到內存,此時會發(fā)生一次磁盤IO,然后再通過二分法,根據主鍵值1,到索引頁5中快速的和各個目錄項中的最小主鍵值對比一下,然后找到下一個索引頁3,通過索引頁3又可以定位到下一個索引頁1。
在這顆B+索引樹中,通過二分法對比最小主鍵值的方式,最終在索引頁1中發(fā)現,原來主鍵值為1的那條數據,是位于數據頁1中。此時,就可以針對性地把數據頁1加載到內存,然后在內存中就可以查到主鍵為1的數據了。
這樣的方式不需要像無索引一樣全表掃描,挨個加載數據頁到內存中,而是利用索引頁,通過高效的二分法查找,很快就可以定位到數據具體是在哪個數據頁中。
在這個過程中就算是上千萬級別的數據量,也可以做到只發(fā)生個位數磁盤IO,就可以查詢到數據,這也是為什么用了索引之后查詢的效率明顯提高的原因。
所以,SQL優(yōu)化,關鍵在于要想辦法讓SQL語句能利用索引查數據,這樣的話查詢的效率才會上來,但是有時會有很多因素,導致不能讓SQL語句使用索引,這也是SQL優(yōu)化的一個關鍵點。