在我們?nèi)粘孟到y(tǒng)中，讀寫比率約為10：1，并且插入操作和一般更新操作很少會出現(xiàn)性能問題。在生產(chǎn)環(huán)境中，我們遇到最多，最容易出現(xiàn)問題，或者遇到一些復雜的查詢操作，因此優(yōu)化查詢語句顯然是當務之急。在加快查詢速度時，您必須提到索引。那么MySQL索引是什么？下文將詳細介紹MySQL索引是什么以及MySQL索引的影響有哪些的問題。

　　MySQL索引是什么？

索引在MySQL中也叫做“鍵”或者"key"，是存儲引擎用于快速找到記錄的一種數(shù)據(jù)結構。索引對于良好的性能非常關鍵，尤其是當表中的數(shù)據(jù)量越來越大時，索引對于性能的影響愈發(fā)重要，減少io次數(shù)，加速查詢。

索引優(yōu)化應該是對查詢性能優(yōu)化最有效的手段了。索引能夠輕易將查詢性能提高好幾個數(shù)量級。

索引相當于字典的音序表，如果要查某個字，如果不使用音序表，則需要從幾百頁中逐頁去查。

強調(diào)：一旦為表創(chuàng)建了索引，以后的查詢最好先查索引，再根據(jù)索引定位的結果去找數(shù)據(jù)

　　你是否對索引存在誤解？

索引是應用程序設計和開發(fā)的一個重要方面。若索引太多，應用程序的性能可能會受到影響。而索引太少，對查詢性能又會產(chǎn)生影響，要找到一個平衡點，這對應用程序的性能至關重要。一些開發(fā)人員總是在事后才想起添加索引----我一直認為，這源于一種錯誤的開發(fā)模式。

如果知道數(shù)據(jù)的使用，從一開始就應該在需要處添加索引。開發(fā)人員往往對數(shù)據(jù)庫的使用停留在應用的層面，比如編寫SQL語句、存儲過程之類，他們甚至可能不知道索引的存在，或認為事后讓相關DBA加上即可。DBA往往不夠了解業(yè)務的數(shù)據(jù)流，而添加索引需要通過監(jiān)控大量的SQL語句進而從中找到問題，這個步驟所需的時間肯定是遠大于初始添加索引所需的時間，并且可能會遺漏一部分的索引。

當然索引也并不是越多越好，我曾經(jīng)遇到過這樣一個問題：某臺MySQL服務器iostat顯示磁盤使用率一直處于100%，經(jīng)過分析后發(fā)現(xiàn)是由于開發(fā)人員添加了太多的索引，在刪除一些不必要的索引之后，磁盤使用率馬上下降為20%?？梢娝饕奶砑右彩欠浅Ｓ屑夹g含量的。

　　MySQL索引有哪些影響？

1、在表中有大量數(shù)據(jù)的前提下，創(chuàng)建索引速度會很慢；

2、在索引創(chuàng)建完畢后，對表的查詢性能會發(fā)幅度提升，但是寫性能會降低；

本質都是：通過不斷地縮小想要獲取數(shù)據(jù)的范圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是說，有了這種索引機制，我們可以總是用同一種查找方式來鎖定數(shù)據(jù)。

數(shù)據(jù)庫也是一樣，但顯然要復雜的多，因為不僅面臨著等值查詢，還有范圍查詢（>、<、between、in）、模糊查詢（like）、并集查詢（or）等等。數(shù)據(jù)庫應該選擇怎么樣的方式來應對所有的問題呢？我們回想字典的例子，能不能把數(shù)據(jù)分成段，然后分段查詢呢？

最簡單的如果1000條數(shù)據(jù)，1到100分成第一段，101到200分成第二段，201到300分成第三段......這樣查第250條數(shù)據(jù)，只要找第三段就可以了，一下子去除了90%的無效數(shù)據(jù)。但如果是1千萬的記錄呢，分成幾段比較好?稍有算法基礎的同學會想到搜索樹，其平均復雜度是lgN，具有不錯的查詢性能。

但這里我們忽略了一個關鍵的問題，復雜度模型是基于每次相同的操作成本來考慮的。而數(shù)據(jù)庫實現(xiàn)比較復雜，一方面數(shù)據(jù)是保存在磁盤上的，另外一方面為了提高性能，每次又可以把部分數(shù)據(jù)讀入內(nèi)存來計算，因為我們知道訪問磁盤的成本大概是訪問內(nèi)存的十萬倍左右，所以簡單的搜索樹難以滿足復雜的應用場景。

以上就是關于MySQL索引是什么的相關內(nèi)容介紹，想了解更多關于MySQL數(shù)據(jù)庫的信息，請繼續(xù)關注中培偉業(yè)。