MySQL數(shù)據(jù)庫索引為什么能提高數(shù)據(jù)訪問性能

這篇文章主要講解了“MySQL數(shù)據(jù)庫索引為什么能提高數(shù)據(jù)訪問性能”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MySQL數(shù)據(jù)庫索引為什么能提高數(shù)據(jù)訪問性能”吧！

索引為什么能提高數(shù)據(jù)訪問性能?
　　很多人只知道索引能夠提高數(shù)據(jù)庫的性能，但并不是特別了解其原理，其實我們可以用一個生活中的示例來理解。
　 　我們讓一位不太懂計算機的朋友去圖書館確認(rèn)一本叫做《MySQL性能調(diào)優(yōu)與架構(gòu)設(shè)計》的書是否在藏，這樣對他說：“請幫我借一本計算機類的數(shù)據(jù)庫書籍， 是屬于 MySQL 數(shù)據(jù)庫范疇的，叫做《MySQL性能調(diào)優(yōu)與架構(gòu)設(shè)計》”。朋友會根據(jù)所屬類別，前往存放“計算機”書籍區(qū)域的書架，然后再尋找“數(shù)據(jù)庫”類存放位置，再找 到一堆講述“MySQL”的書籍，最后可能發(fā)現(xiàn)目標(biāo)在藏(也可能已經(jīng)借出不在書架上)。
　　在這個過程中： “計算機”->“數(shù)據(jù)庫”->“MySQL”->“在藏”->《MySQL性能調(diào)優(yōu)與架構(gòu)設(shè)計》其實就是一個“根據(jù)索引查找數(shù) 據(jù)”的典型案例，“計算機”->“數(shù)據(jù)庫”->“MySQL”->“在藏” 就是朋友查找書籍的索引。
　　假設(shè)沒有這個 索引，那查找這本書的過程會變成怎樣呢?朋友只能從圖書館入口一個書架一個書架的“遍歷”，直到找到《MySQL性能調(diào)優(yōu)與架構(gòu)設(shè)計》這本書為止。如果幸 運，可能在第一個書架就找到。但如果不幸呢，那就慘了，可能要將整個圖書館所有的書架都找一遍才能找到我們想要的這本書。
　　注：這個例子 中的“索引”是記錄在朋友大腦中的，實際上，每個圖書館都會有一個非常全的實際存在的索引系統(tǒng)(大多位于入口顯眼處)，由很多個貼上了明顯標(biāo)簽的小抽屜構(gòu) 成。這個索引系統(tǒng)中存放這非常齊全詳盡的索引數(shù)據(jù)，標(biāo)識出我們需要查找的“目標(biāo)”在某個區(qū)域的某個書架上。而且每當(dāng)有新的書籍入庫，舊的書籍銷毀以及書記 信息修改，都需要對索引系統(tǒng)進行及時的修正。
　　下面我們通過上面這個生活中的小示例，來分析一下索引，看看能的出哪些結(jié)論?
　　索引有哪些“副作用”?
　　圖書的變更(增，刪，改)都需要修訂索引，索引存在額外的維護成本
　　查找翻閱索引系統(tǒng)需要消耗時間，索引存在額外的訪問成本
　　這個索引系統(tǒng)需要一個地方來存放，索引存在額外的空間成本
　　索引是不是越多越好?
　　如果我們的這個圖書館只是一個進出中轉(zhuǎn)站，里面的新書進來后很快就會轉(zhuǎn)發(fā)去其他圖書館而從這個館藏中“清除”，那我們的索引就只會不斷的修改，而很少會被用來查找圖書
　　所以，對于類似于這樣的存在非常大更新量的數(shù)據(jù)，索引的維護成本會非常高，如果其檢索需求很少，而且對檢索效率并沒有非常高的要求的時候，我們并不建議創(chuàng)建索引，或者是盡量減少索引。
　　如果我們的書籍量少到只有幾本或者就只有一個書架，索引并不會帶來什么作用，甚至可能還會浪費一些查找索引所花費的時間。
　　所以，對于數(shù)據(jù)量極小到通過索引檢索還不如直接遍歷來得快的數(shù)據(jù)，也并不適合使用索引。
　　如果我們的圖書館只有一個10平方的面積，現(xiàn)在連放書架都已經(jīng)非常擁擠，而且館藏還在不斷增加，我們還能考慮創(chuàng)建索引嗎?
　　所以，當(dāng)我們連存儲基礎(chǔ)數(shù)據(jù)的空間都捉襟見肘的時候，我們也應(yīng)該盡量減少低效或者是去除索引。
　　索引該如何設(shè)計才高效?
　 　如果我們僅僅只是這樣告訴對方的：“幫我確認(rèn)一本數(shù)據(jù)庫類別的講述 MySQL 的叫做《MySQL性能調(diào)優(yōu)與架構(gòu)設(shè)計》的書是否在藏”，結(jié)果又會如何呢?朋友只能一個大類區(qū)域一個大類區(qū)域的去尋找“數(shù)據(jù)庫”類別，然后再找到 “MySQL”范疇，再看到我們所需是否在藏。由于我們少說了一個“計算機類”，朋友就必須到每一個大類去尋找。
　　所以，我們應(yīng)該盡量讓查找條件盡可能多的在索引中，盡可能通過索引完成所有過濾，回表只是取出額外的數(shù)據(jù)字段。
　 　如果我們是這樣說的：“幫我確認(rèn)一本講述 MySQL 的數(shù)據(jù)庫范疇的計算機叢書，叫做《MySQL性能調(diào)優(yōu)與架構(gòu)設(shè)計》，看是否在藏”。如果這位朋友并不知道計算機是一個大類，也不知道數(shù)據(jù)庫屬于計算機大 類，那這位朋友就悲劇了。首先他得遍歷每個類別確認(rèn)“MySQL”存在于哪些類別中，然后從包含 “MySQL” 書籍中再看有哪些是“數(shù)據(jù)庫”范疇的(有可能部分是講述PHP或者其他開發(fā)語言的)，然后再排除非計算機類的(雖然可能并沒有必要)，然后才能確認(rèn)。
　　所以，字段的順序?qū)M合索引效率有至關(guān)重要的作用，過濾效果越好的字段需要更靠前。
　 　如果我們還有這樣一個需求(雖然基本不可能)：“幫我將圖書館中所有的計算機圖書借來”。朋友如果通過索引來找，每次都到索引柜找到計算機書籍所在的區(qū) 域，然后從書架上搬下一格(假設(shè)只能以一格為單位從書架上取下，類比數(shù)據(jù)庫中以block/page為單位讀取)，取出第一本，然后再從索引柜找到計算機 圖書所在區(qū)域，再搬下一格，取出一本… 如此往復(fù)直至取完所有的書。如果他不通過索引來找又會怎樣呢?他需要從地一個書架一直往后找，當(dāng)找到計算機的書，搬下一格，取出所有計算機的書，再往后， 直至所有書架全部看一遍。在這個過程中，如果計算機類書籍較多，通過索引來取所花費的時間很可能要大于直接遍歷，因為不斷往復(fù)的索引翻閱所消耗的時間會非 常長。(延伸閱讀：這里有一篇以前寫的關(guān)于Oracle的文章，索引掃描還是全表掃描(Index Scan Or Full Table Scan))
　　所以，當(dāng)我們需要讀取的數(shù)據(jù)量占整個數(shù)據(jù)量的比例較大抑或者說索引的過濾效果并不是太好的時候，使用索引并不一定優(yōu)于全表掃描。
　 　如果我們的朋友不知道“數(shù)據(jù)庫”這個類別可以屬于“計算機”這個大類，抑或者圖書館的索引系統(tǒng)中這兩個類別屬性并沒有關(guān)聯(lián)關(guān)系，又會怎樣呢?也就是說， 朋友得到的是2個獨立的索引，一個是告知“計算機”這個大類所在的區(qū)域，一個是“數(shù)據(jù)庫”這個小類所在的區(qū)域(很可能是多個區(qū)域)，那么他只能二者選其一 來搜索我的需求。即使朋友可以分別通過2個索引檢索然后自己在腦中取交集再找，那這樣的效率實際過程中也會比較低下。
　　所以，在實際使用過程中，一次數(shù)據(jù)訪問一般只能利用到1個索引，這一點在索引創(chuàng)建過程中一定要注意，不是說一條SQL語句中Where子句里面每個條件都有索引能對應(yīng)上就可以了。

感謝各位的閱讀，以上就是“MySQL數(shù)據(jù)庫索引為什么能提高數(shù)據(jù)訪問性能”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對MySQL數(shù)據(jù)庫索引為什么能提高數(shù)據(jù)訪問性能這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！