再有人問你MySQL是如何查詢數(shù)據(jù)的，請(qǐng)把這篇文章甩給他！
SELECT * FROM student WHERE name='wx' AND age=1
classId=1,name=wx,age=1,id=1;
classId=1,name=xq,age=2,id=2;
classId=1,name=wx,age=1,id=3;
classId=2,name=zs,age=3,id=4;
SELECT * FROM student WHERE age=1
范圍查找規(guī)則，相信這個(gè)也是大家最經(jīng)常使用的原則了，例如像下面的SQL
SELECT * FROM student WHERE classId > 1 AND classId < 4
因?yàn)榇藭r(shí)由聯(lián)合索引（classId,name,age）構(gòu)建出來的 B+ 樹中的數(shù)據(jù)是根據(jù) classId,name,age 去排序的。
所以此時(shí)是能夠根據(jù) classId 查詢到一個(gè)范圍中的數(shù)據(jù)的，雖然他們可能不在同一個(gè)數(shù)據(jù)頁中，但是我們說過了，數(shù)據(jù)頁之間是通過雙向鏈表進(jìn)行連接的。所以 此時(shí)針對(duì) classId 的范圍查找依舊是能走索引的。繼續(xù)看如果條件是這樣子的
SELECT * FROM student WHERE classId > 1 AND classId < 4 and name > a AND name < x
你是不是覺得前面的 classId 是符合范圍查找的，然后在查詢出來的結(jié)果中繼續(xù)范圍查找 name。
但實(shí)際上并不是這樣子的，因?yàn)槲覀冋f了聯(lián)合索引（classId,name,age）是按照 calssId、name、age 依次去排序的，因?yàn)榇藭r(shí) classId 的順序確定以后，是不需要根據(jù) name 排序的，也就是說在 classId 的范圍內(nèi) name 是無序的，聽不明白？沒關(guān)系，看我畫圖
現(xiàn)在我們依次插入的數(shù)據(jù)是上面的四條，因?yàn)樵诓迦氲臅r(shí)候是可以直接根據(jù) classId 就能夠確定下這四條記錄的順序了。
所以此時(shí)是根本不會(huì)去管后面的 name 或者是 age 是什么順序的，或許你可能覺得如果他們的 class Id 一樣呢？
好，我就來一點(diǎn)一點(diǎn)排除你心中的疑惑，看下面這張圖
我們假設(shè)第三條記錄的 calssId 和第二條記錄的 classId 字段值是一樣的，那這個(gè)時(shí)候才會(huì)去根據(jù) name 判斷。
結(jié)果發(fā)現(xiàn) aa 是小于 zz 的，這樣就會(huì)把 name 值更小的排在前面，但是為什么我上面還會(huì)說按照 calssId 排序好了以后 name 是無序的呢？
因?yàn)槲覀冋f的第二種情況（classId 相同）是屬于特殊情況，我們不能使用特殊的情況來下一般性的結(jié)論，age 同理。
所以記住了：針對(duì)于范圍查找只要聯(lián)合索引的最左側(cè)列有效，其他的都無法使用到索引（既然無法使用到索引，那么只能是走全表掃描）
假設(shè)我們有這樣的一條 SQL
SELECT * FROM student WHERE classId = 1 AND name > a AND name < x
首先 calssId 是走索引的，其次 name 也是走索引的。
為什么？你怎么前后說的有矛盾？剛剛才說了范圍的之后第一個(gè)列才能走索引，現(xiàn)在卻說 name 也走索引，name 明明是第二列。
聽我慢慢道來，首先范圍查找只有第一個(gè)列走索引單純針對(duì)的范圍查找，具體原因我已經(jīng)詳細(xì)的解釋了，但是現(xiàn)在如果使用聯(lián)合索引中的第一個(gè)條件去做等值匹配，第二個(gè)去使用范圍查詢走索引是沒問題的，看下面的圖
現(xiàn)在我們首先定位的是 classId=1 這些記錄，這些一定是確定的，但是在 MySQL維護(hù) B+ 樹的時(shí)候，是沒法根據(jù) classId=1 的記錄來直接進(jìn)行排序的。
因?yàn)榇藭r(shí)的 classId 都是1，換句話說，三條記錄的 classId 都是1，MySQL 根本無法確定誰在前面，誰在后面。
所以此時(shí)就需要根據(jù) name 去繼續(xù)判斷，結(jié)果也就是上面圖的樣子。
根據(jù) name 發(fā)現(xiàn)是能夠確定記錄順序的，所以在 classId 等于 1 的記錄中的所有的 name 都是有序的。
這就是為什么等值后面可以范圍的原因（但是一條貫穿始終的原則是：必須是滿足最左匹配原則，也就是前面的記錄必須是確定的，這樣子才能繼續(xù)對(duì)后面的數(shù)據(jù)判斷）。此時(shí)此刻你是不是想大聲的喊一句
到此為止，你現(xiàn)在是否能夠根據(jù)建立的索引來判斷你的 SQL 是否使用到了索引，使用到了哪些索引了呢。
是不是想趕緊的寫幾個(gè)SQL 試試？
別急，一定要看完總結(jié)部分。
上面說道的一些都是最最基本的查詢的一些原則，但是想要實(shí)際運(yùn)用，這里是必須要學(xué)習(xí)的，因?yàn)槲覀兤綍r(shí)寫sql的時(shí)候絕對(duì)離不開分頁。
而分頁基本是也排序組合使用的，所以我們也將這個(gè)放在一起在說。
假設(shè)現(xiàn)在對(duì)name，age，adderss 這三個(gè)字段創(chuàng)建聯(lián)合索引，且在查詢的時(shí)候 SQL 語句是這樣子的:
SELECT name,age,address FROM student ORDER BY name,age,address LIMIT 10
你如果這么寫那 MySQL 就能明白了啊，你是想根據(jù) name,age,address聯(lián)合索引進(jìn)行排序，然后在取前10條記錄，且取的記錄的字段在維護(hù)聯(lián)合索引的 B+ 樹中都是有的，那么此時(shí)就需要再去進(jìn)行回表到聚簇索引中查詢了。
另外 ORDER BY后面的字段的方式一定要一致，也就是說要么全是升序，要么全是降序，不能有的升序有的降序。
說白了就是一般對(duì)什么字段排序就對(duì)哪些字段建立索引，但是升序降序不要混用。
其實(shí)對(duì)于 MySQL 的優(yōu)化看到這里相信大家或多或少也發(fā)現(xiàn)了，優(yōu)化真的沒有所以的規(guī)律和套路，因?yàn)樽詈玫膬?yōu)化是結(jié)合實(shí)際的業(yè)務(wù)區(qū)做調(diào)整。沒有一蹴而就的方式和一勞永逸的方法。
其實(shí)分組查詢優(yōu)化和上面的Order By + limit 優(yōu)化差不多，基本是一個(gè)道理，例如有這樣的 SQL
SELECT count(*) FROM student GROUP BY NAME
如果不對(duì) NAME 建立索引，那么就是將所有的數(shù)據(jù)查詢出來，放在一個(gè)臨時(shí)文件中，然后按照分組的字段將數(shù)據(jù)一組一組的分好。
然后再去執(zhí)行聚合操作（這里就是count(*)操作），這樣子很顯然效率是很低的，所以我們肯定是需要對(duì) NAME 去建立索引的。
這是不是不明白為什么需要會(huì)有臨時(shí)文件？
根據(jù) group by 的語義邏輯，是按照name去做統(tǒng)計(jì)，因?yàn)榇藭r(shí)name并沒有索引，所以按照name去分組首先需要得到一個(gè)根據(jù)name排序的數(shù)據(jù)啊，所以我們就需要有一個(gè)臨時(shí)表，來記錄并統(tǒng)計(jì)結(jié)果。
也就是說我們需要的不就是一個(gè)排好序的結(jié)果嗎？那直接對(duì)name建立索引就可以了。
假設(shè)我們是根據(jù)name建立好了索引，因?yàn)榇藭r(shí)name已經(jīng)是被排好序的了，這個(gè)時(shí)候就可以拿到 group by 的結(jié)果，不需要臨時(shí)表，也不需要再額外排序。
也就是說，如果語句執(zhí)行過程可以一邊讀數(shù)據(jù)，一邊直接得到結(jié)果，是不需要額外內(nèi)存的，否則就需要額外的內(nèi)存，來保存中間結(jié)果。
索引查詢基本原則總結(jié)
我們一般寫 SQL 基本都是【等值 + 范圍】的，這個(gè)是最常見的條件搜索，像這樣子的情況一定要建立好索引，建立索引的根本依據(jù)就是要明白【MySQL 是如何幫我們維護(hù)非主鍵索引的】。
MySQL 是如何幫我們維護(hù)非主鍵索引的
其實(shí)在開頭我已經(jīng)強(qiáng)調(diào)過了，但是為了讓大家在鞏固下，我這里在來說一遍。
對(duì)于主鍵索引，MySQL 就是根據(jù)主鍵字段進(jìn)行排序（一般主鍵字段我們都設(shè)置為自增的，否則真的是在給自己找麻煩，假設(shè)主鍵不是自增的，這還會(huì)導(dǎo)致頁分裂的發(fā)生，這樣就很降低性能了）；
而對(duì)于非主鍵索引（我們一般指聯(lián)合索引）MySQL 同樣會(huì)為我們維護(hù)一個(gè)B+ 樹，只不過這顆B+的葉子結(jié)點(diǎn)（即數(shù)據(jù)頁）上面的保存的數(shù)據(jù)僅僅是索引字段數(shù)據(jù)和主鍵數(shù)據(jù)。
假設(shè)有聯(lián)合索引 name、address、age，這樣在插入數(shù)據(jù)的時(shí)候，MySQL 首先會(huì)根據(jù)name進(jìn)行排序，name一樣就根據(jù)address 排序，address 字段值一樣再根據(jù) age 字段值排序。
age 字段值還一樣，就根據(jù)主鍵字段排序。
這也是為什么會(huì)維護(hù)主鍵字段的原因。
另外為什么對(duì)于非主鍵字段只維護(hù)索引列？因?yàn)榫鄞厮饕ㄍㄟ^維護(hù)主鍵字段的B+樹）中已經(jīng)有全部記錄的值，如果其他的索引再維護(hù)所有的字段，這樣就是在浪費(fèi)空間。
往期推薦
換掉 Maven，我用它！！！
spring：我是如何解決循環(huán)依賴的？
收藏！這些IDE使用技巧，你都知道嗎
直面Java第343期：為什么TOMCAT要破壞雙親委派
深入并發(fā)第013期：拓展synchronized——鎖優(yōu)化
如果你喜歡本文, 請(qǐng)長(zhǎng)按二維碼，關(guān)注 Hollis. 轉(zhuǎn)發(fā)至朋友圈，是對(duì)我最大的支持。 點(diǎn)個(gè) 在看 喜歡是一種感覺 在看是一種支持 ↘↘↘
