MySQL索引

MySQL支持諸多存儲(chǔ)引擎，而各種存儲(chǔ)引擎對(duì)索引的支持也各不相同，因此MySQL數(shù)據(jù)庫(kù)支持多種索引類型，如BTree索引，哈希索引，全文索引等等。

為了避免混亂，本文將只關(guān)注于BTree索引，因?yàn)檫@是平常使用MySQL時(shí)主要打交道的索引。

MySQL官方對(duì)索引的定義為：索引（Index）是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。提取句子主干，就可以得到索引的本質(zhì)：索引是數(shù)據(jù)結(jié)構(gòu)。

MySQL索引原理

索引目的

索引的目的在于提高查詢效率，可以類比字典，如果要查“mysql”這個(gè)單詞，我們肯定需要定位到m字母，然后從下往下找到y(tǒng)字母，再找到剩下的sql。

如果沒(méi)有索引，那么你可能需要把所有單詞看一遍才能找到你想要的，如果我想找到m開(kāi)頭的單詞呢？或者ze開(kāi)頭的單詞呢？是不是覺(jué)得如果沒(méi)有索引，這個(gè)事情根本無(wú)法完成？

咱們?nèi)D書(shū)館借書(shū)也是一樣，如果你要借某一本書(shū)，一定是先找到對(duì)應(yīng)的分類科目，再找到對(duì)應(yīng)的編號(hào)，這是生活中活生生的例子，通用索引，可以加快查詢速度，快速定位。

索引原理

所有索引原理都是一樣的，通過(guò)不斷的縮小想要獲得數(shù)據(jù)的范圍來(lái)篩選出最終想要的結(jié)果，同時(shí)把隨機(jī)的事件變成順序的事件，也就是我們總是通過(guò)同一種查找方式來(lái)鎖定數(shù)據(jù)。

數(shù)據(jù)庫(kù)也是一樣，但顯然要復(fù)雜許多，因?yàn)椴粌H面臨著等值查詢，還有范圍查詢(>、<、between)、模糊查詢(like)、并集查詢(or)、多值匹配（in【in本質(zhì)上屬于多個(gè)or】）等等。數(shù)據(jù)庫(kù)應(yīng)該選擇怎么樣的方式來(lái)應(yīng)對(duì)所有的問(wèn)題呢？

我們回想字典的例子，能不能把數(shù)據(jù)分成段，然后分段查詢呢？最簡(jiǎn)單的如果1000條數(shù)據(jù)，1到100分成第一段，101到200分成第二段，201到300分成第三段……這樣查第250條數(shù)據(jù)，只要找第三段就可以了，一下子去除了90%的無(wú)效數(shù)據(jù)。但如果是1千萬(wàn)的記錄呢，分成幾段比較好？

稍有算法基礎(chǔ)的同學(xué)會(huì)想到搜索樹(shù)，其平均復(fù)雜度是lgN，具有不錯(cuò)的查詢性能。

但這里我們忽略了一個(gè)關(guān)鍵的問(wèn)題，復(fù)雜度模型是基于每次相同的操作成本來(lái)考慮的，數(shù)據(jù)庫(kù)實(shí)現(xiàn)比較復(fù)雜，數(shù)據(jù)保存在磁盤(pán)上，而為了提高性能，每次又可以把部分?jǐn)?shù)據(jù)讀入內(nèi)存來(lái)計(jì)算，因?yàn)槲覀冎涝L問(wèn)磁盤(pán)的成本大概是訪問(wèn)內(nèi)存的十萬(wàn)倍左右，所以簡(jiǎn)單的搜索樹(shù)難以滿足復(fù)雜的應(yīng)用場(chǎng)景。

索引結(jié)構(gòu)

任何一種數(shù)據(jù)結(jié)構(gòu)都不是憑空產(chǎn)生的，一定會(huì)有它的背景和使用場(chǎng)景，我們現(xiàn)在總結(jié)一下，我們需要這種數(shù)據(jù)結(jié)構(gòu)能夠做些什么，其實(shí)很簡(jiǎn)單，那就是：每次查找數(shù)據(jù)時(shí)把磁盤(pán)IO次數(shù)控制在一個(gè)很小的數(shù)量級(jí)，最好是常數(shù)數(shù)量級(jí)。

那么我們就想到如果一個(gè)高度可控的多路搜索樹(shù)是否能滿足需求呢？就這樣，b+樹(shù)應(yīng)運(yùn)而生。

b+樹(shù)的索引結(jié)構(gòu)解釋

淺藍(lán)色的塊我們稱之為一個(gè)磁盤(pán)塊，可以看到每個(gè)磁盤(pán)塊包含幾個(gè)數(shù)據(jù)項(xiàng)（深藍(lán)色所示）和指針（黃色所示），如磁盤(pán)塊1包含數(shù)據(jù)項(xiàng)17和35，包含指針P1、P2、P3，P1表示小于17的磁盤(pán)塊，P2表示在17和35之間的磁盤(pán)塊，P3表示大于35的磁盤(pán)塊。真實(shí)的數(shù)據(jù)存在于葉子節(jié)點(diǎn)即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非葉子節(jié)點(diǎn)不存儲(chǔ)真實(shí)的數(shù)據(jù)，只存儲(chǔ)指引搜索方向的數(shù)據(jù)項(xiàng)，如17、35并不真實(shí)存在于數(shù)據(jù)表中。

b+樹(shù)的查找過(guò)程

如圖所示，如果要查找數(shù)據(jù)項(xiàng)29，那么首先會(huì)把磁盤(pán)塊1由磁盤(pán)加載到內(nèi)存，此時(shí)發(fā)生一次IO，在內(nèi)存中用二分查找確定29在17和35之間，鎖定磁盤(pán)塊1的P2指針，內(nèi)存時(shí)間因?yàn)榉浅６?#xff08;相比磁盤(pán)的IO）可以忽略不計(jì)，通過(guò)磁盤(pán)塊1的P2指針的磁盤(pán)地址把磁盤(pán)塊3由磁盤(pán)加載到內(nèi)存，發(fā)生第二次IO，29在26和30之間，鎖定磁盤(pán)塊3的P2指針，通過(guò)指針加載磁盤(pán)塊8到內(nèi)存，發(fā)生第三次IO，同時(shí)內(nèi)存中做二分查找找到29，結(jié)束查詢，總計(jì)三次IO。

真實(shí)的情況是，3層的b+樹(shù)可以表示上百萬(wàn)的數(shù)據(jù)，如果上百萬(wàn)的數(shù)據(jù)查找只需要三次IO，性能提高將是巨大的，如果沒(méi)有索引，每個(gè)數(shù)據(jù)項(xiàng)都要發(fā)生一次IO，那么總共需要百萬(wàn)次的IO，顯然成本非常非常高。

b+樹(shù)性質(zhì)

1、通過(guò)上面的分析，我們知道間越小，數(shù)據(jù)項(xiàng)的數(shù)量越多，樹(shù)的高度越低。這就是為什么每個(gè)數(shù)據(jù)項(xiàng)，即索引字段要盡量的小，比如int占4字節(jié)，要比bigint8字節(jié)少一半。

這也是為什么b+樹(shù)要求把真實(shí)的數(shù)據(jù)放到葉子節(jié)點(diǎn)而不是內(nèi)層節(jié)點(diǎn)，一旦放到內(nèi)層節(jié)點(diǎn)，磁盤(pán)塊的數(shù)據(jù)項(xiàng)會(huì)大幅度下降，導(dǎo)致樹(shù)增高。當(dāng)數(shù)據(jù)項(xiàng)等于1時(shí)將會(huì)退化成線性表。

2、當(dāng)b+樹(shù)的數(shù)據(jù)項(xiàng)是復(fù)合的數(shù)據(jù)結(jié)構(gòu)，比如(name,age,sex)的時(shí)候，b+數(shù)是按照從左到右的順序來(lái)建立搜索樹(shù)的，比如當(dāng)(張三,20,F)這樣的數(shù)據(jù)來(lái)檢索的時(shí)候，b+樹(shù)會(huì)優(yōu)先比較name來(lái)確定下一步的所搜方向，如果name相同再依次比較age和sex，最后得到檢索的數(shù)據(jù)；

但當(dāng)(20,F)這樣的沒(méi)有name的數(shù)據(jù)來(lái)的時(shí)候，b+樹(shù)就不知道下一步該查哪個(gè)節(jié)點(diǎn)，因?yàn)榻⑺阉鳂?shù)的時(shí)候name就是第一個(gè)比較因子，必須要先根據(jù)name來(lái)搜索才能知道下一步去哪里查詢。

比如當(dāng)(張三,F)這樣的數(shù)據(jù)來(lái)檢索時(shí)，b+樹(shù)可以用name來(lái)指定搜索方向，但下一個(gè)字段age的缺失，所以只能把名字等于張三的數(shù)據(jù)都找到，然后再匹配性別是F的數(shù)據(jù)了， 這個(gè)是非常重要的性質(zhì)，即索引的最左匹配特性。

MySQL 索引實(shí)現(xiàn)

在MySQL中，索引屬于存儲(chǔ)引擎級(jí)別的概念，不同存儲(chǔ)引擎對(duì)索引的實(shí)現(xiàn)方式是不同的，本文主要討論MyISAM和InnoDB兩個(gè)存儲(chǔ)引擎的索引實(shí)現(xiàn)方式。

MyISAM索引實(shí)現(xiàn)

MyISAM引擎使用B+Tree作為索引結(jié)構(gòu)，葉節(jié)點(diǎn)的data域存放的是數(shù)據(jù)記錄的地址。

下圖是MyISAM索引的原理圖：

這里設(shè)表一共有三列，假設(shè)我們以Col1為主鍵，則上圖便是一個(gè)MyISAM表的主索引（Primary key）示意圖。可以看出MyISAM的索引文件僅僅保存數(shù)據(jù)記錄的地址。

在MyISAM中，主索引和輔助索引（Secondary key）在結(jié)構(gòu)上沒(méi)有任何區(qū)別，只是主索引要求key是唯一的，而輔助索引的key可以重復(fù)。如果我們?cè)贑ol2上建立一個(gè)輔助索引，則此索引的結(jié)構(gòu)如下圖所示：

同樣也是一顆B+Tree，data域保存數(shù)據(jù)記錄的地址。

因此，MyISAM中索引檢索的算法為首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，則取出其data域的值，然后以data域的值為地址，讀取相應(yīng)數(shù)據(jù)記錄。

MyISAM的索引方式也叫做“非聚集”的，之所以這么稱呼是為了與InnoDB的聚集索引區(qū)分。

InnoDB索引實(shí)現(xiàn)

雖然InnoDB也使用B+Tree作為索引結(jié)構(gòu)，但具體實(shí)現(xiàn)方式卻與MyISAM截然不同。

第一個(gè)重大區(qū)別是InnoDB的數(shù)據(jù)文件本身就是索引文件。從上文知道，MyISAM索引文件和數(shù)據(jù)文件是分離的，索引文件僅保存數(shù)據(jù)記錄的地址。

而在InnoDB中，表數(shù)據(jù)文件本身就是按B+Tree組織的一個(gè)索引結(jié)構(gòu)，這棵樹(shù)的葉節(jié)點(diǎn)data域保存了完整的數(shù)據(jù)記錄。這個(gè)索引的key是數(shù)據(jù)表的主鍵，因此InnoDB表數(shù)據(jù)文件本身就是主索引。

上圖是InnoDB主索引（同時(shí)也是數(shù)據(jù)文件）的示意圖，可以看到葉節(jié)點(diǎn)包含了完整的數(shù)據(jù)記錄。這種索引叫做聚集索引。

因?yàn)镮nnoDB的數(shù)據(jù)文件本身要按主鍵聚集，所以InnoDB要求表必須有主鍵（MyISAM可以沒(méi)有），如果沒(méi)有顯式指定，則MySQL系統(tǒng)會(huì)自動(dòng)選擇一個(gè)可以唯一標(biāo)識(shí)數(shù)據(jù)記錄的列作為主鍵，如果不存在這種列，則MySQL自動(dòng)為InnoDB表生成一個(gè)隱含字段作為主鍵，這個(gè)字段長(zhǎng)度為6個(gè)字節(jié)，類型為長(zhǎng)整形。

第二個(gè)與MyISAM索引的不同是InnoDB的輔助索引data域存儲(chǔ)相應(yīng)記錄主鍵的值而不是地址。換句話說(shuō)，InnoDB的所有輔助索引都引用主鍵作為data域。

例如，下圖為定義在Col3上的一個(gè)輔助索引：

這里以英文字符的ASCII碼作為比較準(zhǔn)則。聚集索引這種實(shí)現(xiàn)方式使得按主鍵的搜索十分高效，但是輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然后用主鍵到主索引中檢索獲得記錄。

了解不同存儲(chǔ)引擎的索引實(shí)現(xiàn)方式對(duì)于正確使用和優(yōu)化索引都非常有幫助，例如知道了InnoDB的索引實(shí)現(xiàn)后，就很容易明白為什么不建議使用過(guò)長(zhǎng)的字段作為主鍵，因?yàn)樗休o助索引都引用主索引，過(guò)長(zhǎng)的主索引會(huì)令輔助索引變得過(guò)大。

再例如，用非單調(diào)的字段作為主鍵在InnoDB中不是個(gè)好主意，因?yàn)镮nnoDB數(shù)據(jù)文件本身是一顆B+Tree，非單調(diào)的主鍵會(huì)造成在插入新記錄時(shí)數(shù)據(jù)文件為了維持B+Tree的特性而頻繁的分裂調(diào)整，十分低效，而使用自增字段作為主鍵則是一個(gè)很好的選擇。

如何建立合適的索引

建立索引的原理

一個(gè)最重要的原則是最左前綴原理，在提這個(gè)之前要先說(shuō)下聯(lián)合索引，MySQL中的索引可以以一定順序引用多個(gè)列，這種索引叫做聯(lián)合索引，一般的，一個(gè)聯(lián)合索引是一個(gè)有序元組，其中各個(gè)元素均為數(shù)據(jù)表的一列。

另外，單列索引可以看成聯(lián)合索引元素?cái)?shù)為1的特例。

索引匹配的最左原則具體是說(shuō)，假如索引列分別為A，B，C，順序也是A，B，C：

• 那么查詢的時(shí)候，如果查詢【A】【A，B】 【A，B，C】，那么可以通過(guò)索引查詢

• 如果查詢的時(shí)候，采用【A，C】，那么C這個(gè)雖然是索引，但是由于中間缺失了B，因此C這個(gè)索引是用不到的，只能用到A索引

• 如果查詢的時(shí)候，采用【B】 【B，C】 【C】，由于沒(méi)有用到第一列索引，不是最左前綴，那么后面的索引也是用不到了

• 如果查詢的時(shí)候，采用范圍查詢，并且是最左前綴，也就是第一列索引，那么可以用到索引，但是范圍后面的列無(wú)法用到索引

因?yàn)樗饕m然加快了查詢速度，但索引也是有代價(jià)的：索引文件本身要消耗存儲(chǔ)空間，同時(shí)索引會(huì)加重插入、刪除和修改記錄時(shí)的負(fù)擔(dān)，另外，MySQL在運(yùn)行時(shí)也要消耗資源維護(hù)索引，因此索引并不是越多越好

在使用InnoDB存儲(chǔ)引擎時(shí)，如果沒(méi)有特別的需要，請(qǐng)永遠(yuǎn)使用一個(gè)與業(yè)務(wù)無(wú)關(guān)的自增字段作為主鍵。

如果從數(shù)據(jù)庫(kù)索引優(yōu)化角度看，使用InnoDB引擎而不使用自增主鍵絕對(duì)是一個(gè)糟糕的主意。

InnoDB使用聚集索引，數(shù)據(jù)記錄本身被存于主索引（一顆B+Tree）的葉子節(jié)點(diǎn)上。

這就要求同一個(gè)葉子節(jié)點(diǎn)內(nèi)（大小為一個(gè)內(nèi)存頁(yè)或磁盤(pán)頁(yè)）的各條數(shù)據(jù)記錄按主鍵順序存放，因此每當(dāng)有一條新的記錄插入時(shí)，MySQL會(huì)根據(jù)其主鍵將其插入適當(dāng)?shù)墓?jié)點(diǎn)和位置，如果頁(yè)面達(dá)到裝載因子（InnoDB默認(rèn)為15/16），則開(kāi)辟一個(gè)新的頁(yè)（節(jié)點(diǎn)）。

如果表使用自增主鍵，那么每次插入新的記錄，記錄就會(huì)順序添加到當(dāng)前索引節(jié)點(diǎn)的后續(xù)位置，當(dāng)一頁(yè)寫(xiě)滿，就會(huì)自動(dòng)開(kāi)辟一個(gè)新的頁(yè)。如下：

這樣就會(huì)形成一個(gè)緊湊的索引結(jié)構(gòu)，近似順序填滿。由于每次插入時(shí)也不需要移動(dòng)已有數(shù)據(jù)，因此效率很高，也不會(huì)增加很多開(kāi)銷在維護(hù)索引上。

如果使用非自增主鍵（如果身份證號(hào)或?qū)W號(hào)等），由于每次插入主鍵的值近似于隨機(jī)，因此每次新紀(jì)錄都要被插到現(xiàn)有索引頁(yè)得中間某個(gè)位置，如下：

此時(shí)MySQL不得不為了將新記錄插到合適位置而移動(dòng)數(shù)據(jù)，甚至目標(biāo)頁(yè)面可能已經(jīng)被回寫(xiě)到磁盤(pán)上而從緩存中清掉，此時(shí)又要從磁盤(pán)上讀回來(lái)，這增加了很多開(kāi)銷，同時(shí)頻繁的移動(dòng)、分頁(yè)操作造成了大量的碎片，得到了不夠緊湊的索引結(jié)構(gòu)，后續(xù)不得不通過(guò)OPTIMIZE TABLE來(lái)重建表并優(yōu)化填充頁(yè)面。

因此，只要可以，請(qǐng)盡量在InnoDB上采用自增字段做主鍵。

建立索引的常用技巧

1、最左前綴匹配原則，非常重要的原則，mysql會(huì)一直向右匹配直到遇到范圍查詢(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調(diào)整。

2、=和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢優(yōu)化器會(huì)幫你優(yōu)化成索引可以識(shí)別的形式

3、盡量選擇區(qū)分度高的列作為索引,區(qū)分度的公式是count(distinct col)/count(*)，表示字段不重復(fù)的比例，比例越大我們掃描的記錄數(shù)越少，唯一鍵的區(qū)分度是1，而一些狀態(tài)、性別字段可能在大數(shù)據(jù)面前區(qū)分度就是0，那可能有人會(huì)問(wèn)，這個(gè)比例有什么經(jīng)驗(yàn)值嗎？使用場(chǎng)景不同，這個(gè)值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃描10條記錄

4、索引列不能參與計(jì)算，保持列“干凈”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很簡(jiǎn)單，b+樹(shù)中存的都是數(shù)據(jù)表中的字段值，但進(jìn)行檢索時(shí)，需要把所有元素都應(yīng)用函數(shù)才能比較，顯然成本太大。所以語(yǔ)句應(yīng)該寫(xiě)成create_time = unix_timestamp(’2014-05-29’);

5、盡量的擴(kuò)展索引，不要新建索引。比如表中已經(jīng)有a的索引，現(xiàn)在要加(a,b)的索引，那么只需要修改原來(lái)的索引即可，當(dāng)然要考慮原有數(shù)據(jù)和線上使用情況

MySQL優(yōu)化

配置優(yōu)化

配置優(yōu)化指的MySQL 的 server端的配置，一般對(duì)于業(yè)務(wù)方而言，可以不用關(guān)注，畢竟會(huì)有專門(mén)的DBA來(lái)處理，但是對(duì)于原理的了解，我想，我們開(kāi)發(fā)，是需要了解的。

MySQL優(yōu)化，也可以參考：超級(jí)全面的MySQL優(yōu)化面試解析

基本配置

innodb_buffer_pool_size

這是安裝完InnoDB后第一個(gè)應(yīng)該設(shè)置的選項(xiàng)。緩沖池是數(shù)據(jù)和索引緩存的地方：這個(gè)值越大越好，這能保證你在大多數(shù)的讀取操作時(shí)使用的是內(nèi)存而不是硬盤(pán)。

典型的值是5-6GB(8GB內(nèi)存)，20-25GB(32GB內(nèi)存)，100-120GB(128GB內(nèi)存)。

innodb_log_file_size

這是redo日志的大小。redo日志被用于確保寫(xiě)操作快速而可靠并且在崩潰時(shí)恢復(fù)。一直到MySQL 5.1，它都難于調(diào)整，因?yàn)橐环矫婺阆胱屗髞?lái)提高性能，另一方面你想讓它更小來(lái)使得崩潰后更快恢復(fù)。

幸運(yùn)的是從MySQL 5.5之后，崩潰恢復(fù)的性能的到了很大提升，這樣你就可以同時(shí)擁有較高的寫(xiě)入性能和崩潰恢復(fù)性能了。

一直到MySQL 5.5，redo日志的總尺寸被限定在4GB(默認(rèn)可以有2個(gè)log文件)。這在MySQL 5.6里被提高了。如果你知道你的應(yīng)用程序需要頻繁的寫(xiě)入數(shù)據(jù)并且你使用的時(shí)MySQL 5.6，你可以一開(kāi)始就把它這是成4G。

max_connections

如果你經(jīng)常看到‘Too many connections'錯(cuò)誤，是因?yàn)閙ax_connections的值太低了。這非常常見(jiàn)因?yàn)閼?yīng)用程序沒(méi)有正確的關(guān)閉數(shù)據(jù)庫(kù)連接，你需要比默認(rèn)的151連接數(shù)更大的值。

max_connection值被設(shè)高了(例如1000或更高)之后一個(gè)主要缺陷是當(dāng)服務(wù)器運(yùn)行1000個(gè)或更高的活動(dòng)事務(wù)時(shí)會(huì)變的沒(méi)有響應(yīng)。在應(yīng)用程序里使用連接池或者在MySQL里使用進(jìn)程池有助于解決這一問(wèn)題。

InnoDB配置

innodb_file_per_table

這項(xiàng)設(shè)置告知InnoDB是否需要將所有表的數(shù)據(jù)和索引存放在共享表空間里（innodb_file_per_table = OFF） 或者為每張表的數(shù)據(jù)單獨(dú)放在一個(gè).ibd文件（innodb_file_per_table = ON）。每張表一個(gè)文件允許你在drop、truncate或者rebuild表時(shí)回收磁盤(pán)空間。

這對(duì)于一些高級(jí)特性也是有必要的，比如數(shù)據(jù)壓縮。但是它不會(huì)帶來(lái)任何性能收益。你不想讓每張表一個(gè)文件的主要場(chǎng)景是：有非常多的表（比如10k+）。MySQL 5.6中，這個(gè)屬性默認(rèn)值是ON，因此大部分情況下你什么都不需要做。

對(duì)于之前的版本你必需在加載數(shù)據(jù)之前將這個(gè)屬性設(shè)置為ON，因?yàn)樗粚?duì)新創(chuàng)建的表有影響。

innodb_flush_log_at_trx_commit

默認(rèn)值為1，表示InnoDB完全支持ACID特性。當(dāng)你的主要關(guān)注點(diǎn)是數(shù)據(jù)安全的時(shí)候這個(gè)值是最合適的，比如在一個(gè)主節(jié)點(diǎn)上。

但是對(duì)于磁盤(pán)（讀寫(xiě)）速度較慢的系統(tǒng)，它會(huì)帶來(lái)很巨大的開(kāi)銷，因?yàn)槊看螌⒏淖僨lush到redo日志都需要額外的fsyncs。

將它的值設(shè)置為2會(huì)導(dǎo)致不太可靠（reliable）因?yàn)樘峤坏氖聞?wù)僅僅每秒才flush一次到redo日志，但對(duì)于一些場(chǎng)景是可以接受的，比如對(duì)于主節(jié)點(diǎn)的備份節(jié)點(diǎn)這個(gè)值是可以接受的。

如果值為0速度就更快了，但在系統(tǒng)崩潰時(shí)可能丟失一些數(shù)據(jù)：只適用于備份節(jié)點(diǎn)。

innodb_flush_method

這項(xiàng)配置決定了數(shù)據(jù)和日志寫(xiě)入硬盤(pán)的方式。一般來(lái)說(shuō)，如果你有硬件RAID控制器，并且其獨(dú)立緩存采用write-back機(jī)制，并有著電池?cái)嚯姳Ｗo(hù)，那么應(yīng)該設(shè)置配置為O_DIRECT；否則，大多數(shù)情況下應(yīng)將其設(shè)為fdatasync（默認(rèn)值）。

sysbench是一個(gè)可以幫助你決定這個(gè)選項(xiàng)的好工具。

innodb_log_buffer_size

這項(xiàng)配置決定了為尚未執(zhí)行的事務(wù)分配的緩存。其默認(rèn)值（1MB）一般來(lái)說(shuō)已經(jīng)夠用了，但是如果你的事務(wù)中包含有二進(jìn)制大對(duì)象或者大文本字段的話，這點(diǎn)緩存很快就會(huì)被填滿并觸發(fā)額外的I/O操作。看看Innodb_log_waits狀態(tài)變量，如果它不是0，增加innodb_log_buffer_size。

其他設(shè)置

query_cache_size

query cache（查詢緩存）是一個(gè)眾所周知的瓶頸，甚至在并發(fā)并不多的時(shí)候也是如此。

最佳選項(xiàng)是將其從一開(kāi)始就停用，設(shè)置query_cache_size = 0（現(xiàn)在MySQL 5.6的默認(rèn)值）并利用其他方法加速查詢：優(yōu)化索引、增加拷貝分散負(fù)載或者啟用額外的緩存（比如memcache或redis）。

如果你已經(jīng)為你的應(yīng)用啟用了query cache并且還沒(méi)有發(fā)現(xiàn)任何問(wèn)題，query cache可能對(duì)你有用。這是如果你想停用它，那就得小心了。

log_bin

如果你想讓數(shù)據(jù)庫(kù)服務(wù)器充當(dāng)主節(jié)點(diǎn)的備份節(jié)點(diǎn)，那么開(kāi)啟二進(jìn)制日志是必須的。如果這么做了之后，還別忘了設(shè)置server_id為一個(gè)唯一的值。

就算只有一個(gè)服務(wù)器，如果你想做基于時(shí)間點(diǎn)的數(shù)據(jù)恢復(fù)，這（開(kāi)啟二進(jìn)制日志）也是很有用的：從你最近的備份中恢復(fù)（全量備份），并應(yīng)用二進(jìn)制日志中的修改（增量備份）。

二進(jìn)制日志一旦創(chuàng)建就將永久保存。所以如果你不想讓磁盤(pán)空間耗盡，你可以用 PURGE BINARY LOGS 來(lái)清除舊文件，或者設(shè)置 expire_logs_days 來(lái)指定過(guò)多少天日志將被自動(dòng)清除。

記錄二進(jìn)制日志不是沒(méi)有開(kāi)銷的，所以如果你在一個(gè)非主節(jié)點(diǎn)的復(fù)制節(jié)點(diǎn)上不需要它的話，那么建議關(guān)閉這個(gè)選項(xiàng)。

skip_name_resolve

當(dāng)客戶端連接數(shù)據(jù)庫(kù)服務(wù)器時(shí)，服務(wù)器會(huì)進(jìn)行主機(jī)名解析，并且當(dāng)DNS很慢時(shí)，建立連接也會(huì)很慢。因此建議在啟動(dòng)服務(wù)器時(shí)關(guān)閉skip_name_resolve選項(xiàng)而不進(jìn)行DNS查找。唯一的局限是之后GRANT語(yǔ)句中只能使用IP地址了，因此在添加這項(xiàng)設(shè)置到一個(gè)已有系統(tǒng)中必須格外小心。

SQL 調(diào)優(yōu)

一般要進(jìn)行SQL調(diào)優(yōu)，那么就說(shuō)有慢查詢的SQL，系統(tǒng)或者server可以開(kāi)啟慢查詢?nèi)罩?#xff0c;尤其是線上系統(tǒng)，一般都會(huì)開(kāi)啟慢查詢?nèi)罩?#xff0c;如果有慢查詢，可以通過(guò)日志來(lái)過(guò)濾。但是知道了有需要優(yōu)化的SQL后，下面要做的就是如何進(jìn)行調(diào)優(yōu)

慢查詢優(yōu)化基本步驟

先運(yùn)行看看是否真的很慢，注意設(shè)置SQL_NO_CACHE

where條件單表查，鎖定最小返回記錄表。這句話的意思是把查詢語(yǔ)句的where都應(yīng)用到表中返回的記錄數(shù)最小的表開(kāi)始查起，單表每個(gè)字段分別查詢，看哪個(gè)字段的區(qū)分度最高

explain查看執(zhí)行計(jì)劃，是否與1預(yù)期一致（從鎖定記錄較少的表開(kāi)始查詢）

order by limit 形式的sql語(yǔ)句讓排序的表優(yōu)先查

了解業(yè)務(wù)方使用場(chǎng)景

加索引時(shí)參照建索引的幾大原則

觀察結(jié)果，不符合預(yù)期繼續(xù)從0分析

常用調(diào)優(yōu)手段

執(zhí)行計(jì)劃explain

在日常工作中，我們有時(shí)會(huì)開(kāi)慢查詢?nèi)ビ涗浺恍﹫?zhí)行時(shí)間比較久的SQL語(yǔ)句，找出這些SQL語(yǔ)句并不意味著完事了，我們常常用到explain這個(gè)命令來(lái)查看一個(gè)這些SQL語(yǔ)句的執(zhí)行計(jì)劃，查看該SQL語(yǔ)句有沒(méi)有使用上了索引，有沒(méi)有做全表掃描，這都可以通過(guò)explain命令來(lái)查看。

所以我們深入了解MySQL的基于開(kāi)銷的優(yōu)化器，還可以獲得很多可能被優(yōu)化器考慮到的訪問(wèn)策略的細(xì)節(jié)，以及當(dāng)運(yùn)行SQL語(yǔ)句時(shí)哪種策略預(yù)計(jì)會(huì)被優(yōu)化器采用。

使用explain 只需要在原有select 基礎(chǔ)上加上explain關(guān)鍵字就可以了，如下：

mysql>?explain?select?*?from?servers; +----+-------------+---------+------+---------------+------+---------+------+------+-------+ |?id?|?select_type?|?table??|?type?|?possible_keys?|?key??|?key_len?|?ref??|?rows?|?Extra?| +----+-------------+---------+------+---------------+------+---------+------+------+-------+ |??1?|?SIMPLE??????|?servers?|?ALL??|?NULL??????????|?NULL?|?NULL????|?NULL?|????1?|?NULL??| +----+-------------+---------+------+---------------+------+---------+------+------+-------+ 1?row?in?set?(0.03?sec)

簡(jiǎn)要解釋下explain各個(gè)字段的含義

• id : 表示SQL執(zhí)行的順序的標(biāo)識(shí),SQL從大到小的執(zhí)行

• select_type：表示查詢中每個(gè)select子句的類型

• table：顯示這一行的數(shù)據(jù)是關(guān)于哪張表的，有時(shí)不是真實(shí)的表名字

• type：表示MySQL在表中找到所需行的方式，又稱“訪問(wèn)類型”。常用的類型有：ALL, index, range, ref, eq_ref, const, system, NULL（從左到右，性能從差到好）

• possible_keys：指出MySQL能使用哪個(gè)索引在表中找到記錄，查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用

• Key：key列顯示MySQL實(shí)際決定使用的鍵（索引），如果沒(méi)有選擇索引，鍵是NULL。

• key_len：表示索引中使用的字節(jié)數(shù)，可通過(guò)該列計(jì)算查詢中使用的索引的長(zhǎng)度（key_len顯示的值為索引字段的最大可能長(zhǎng)度，并非實(shí)際使用長(zhǎng)度，即key_len是根據(jù)表定義計(jì)算而得，不是通過(guò)表內(nèi)檢索出的）

• ref：表示上述表的連接匹配條件，即哪些列或常量被用于查找索引列上的值

• rows：表示MySQL根據(jù)表統(tǒng)計(jì)信息及索引選用情況，估算的找到所需的記錄所需要讀取的行數(shù)，理論上行數(shù)越少，查詢性能越好

• Extra：該列包含MySQL解決查詢的詳細(xì)信息

EXPLAIN的特性

• EXPLAIN不會(huì)告訴你關(guān)于觸發(fā)器、存儲(chǔ)過(guò)程的信息或用戶自定義函數(shù)對(duì)查詢的影響情況

• EXPLAIN不考慮各種Cache

• EXPLAIN不能顯示MySQL在執(zhí)行查詢時(shí)所作的優(yōu)化工作

• 部分統(tǒng)計(jì)信息是估算的，并非精確值

• EXPALIN只能解釋SELECT操作，其他操作要重寫(xiě)為SELECT后查看執(zhí)行計(jì)劃。

實(shí)戰(zhàn)演練

表結(jié)構(gòu)和查詢語(yǔ)句

假如有如下表結(jié)構(gòu)

circlemessage_idx_0?|?CREATE?TABLE?`circlemessage_idx_0`?(`circle_id`?bigint(20)?unsigned?NOT?NULL?COMMENT?'群組id',`from_id`?bigint(20)?unsigned?NOT?NULL?COMMENT?'發(fā)送用戶id',`to_id`?bigint(20)?unsigned?NOT?NULL?COMMENT?'指定接收用戶id',`msg_id`?bigint(20)?unsigned?NOT?NULL?COMMENT?'消息ID',`type`?tinyint(3)?unsigned?NOT?NULL?DEFAULT?'0'?COMMENT?'消息類型',PRIMARY?KEY?(`msg_id`,`to_id`),KEY?`idx_from_circle`?(`from_id`,`circle_id`) )?ENGINE=InnoDB?DEFAULT?CHARSET=utf8mb4?COLLATE=utf8mb4_bin

通過(guò)執(zhí)行計(jì)劃explain分析如下查詢語(yǔ)句

mysql>?explain?select?msg_id?from?circlemessage_idx_0?where??to_id?=?113487?and?circle_id=10019063??and?msg_id>=6273803462253938690??and?from_id?!=?113487?order?by?msg_id?asc?limit?30; +----+-------------+---------------------+-------+-------------------------+---------+---------+------+--------+-------------+ |?id?|?select_type?|?table???????????????|?type??|?possible_keys???????????|?key?????|?key_len?|?ref??|?rows???|?Extra???????| +----+-------------+---------------------+-------+-------------------------+---------+---------+------+--------+-------------+ |??1?|?SIMPLE??????|?circlemessage_idx_0?|?range?|?PRIMARY,idx_from_circle?|?PRIMARY?|?16??????|?NULL?|?349780?|?Using?where?| +----+-------------+---------------------+-------+-------------------------+---------+---------+------+--------+-------------+ 1?row?in?set?(0.00?sec)

mysql>?explain?select?msg_id?from?circlemessage_idx_0?where??to_id?=?113487?and?circle_id=10019063???and?from_id?!=?113487?order?by?msg_id?asc?limit?30; +----+-------------+---------------------+-------+-----------------+---------+---------+------+------+-------------+ |?id?|?select_type?|?table???????????????|?type??|?possible_keys???|?key?????|?key_len?|?ref??|?rows?|?Extra???????| +----+-------------+---------------------+-------+-----------------+---------+---------+------+------+-------------+ |??1?|?SIMPLE??????|?circlemessage_idx_0?|?index?|?idx_from_circle?|?PRIMARY?|?16??????|?NULL?|???30?|?Using?where?| +----+-------------+---------------------+-------+-----------------+---------+---------+------+------+-------------+ 1?row?in?set?(0.00?sec)

問(wèn)題分析

通過(guò)上面兩個(gè)執(zhí)行計(jì)劃可以發(fā)現(xiàn)當(dāng)沒(méi)有msg_id >= xxx這個(gè)查詢條件的時(shí)候，檢索的rows要少很多，并且兩者查詢的時(shí)候都用到了索引，而且用到的還只是主鍵索引。那說(shuō)明索引應(yīng)該是不合理的，沒(méi)有發(fā)揮最大作用。

分析這個(gè)執(zhí)行計(jì)劃可以看到，當(dāng)包含msg_id >= xxx 查詢條件的時(shí)候，rows有34w多行，這種情況，說(shuō)明檢索太多，要么就是表里面確實(shí)有這么大，要么就是索引不合理沒(méi)有用到索引，大都情況是沒(méi)用合理用到索引。

列中所用到的索引也是PRIMARY，那就可能是(msg_id,to_id)的其中一個(gè)，注意我們建立表的時(shí)候msg_id索引的順序是在to_id前面的，因此MySQL查詢一定會(huì)優(yōu)先用msg_id索引，在使用了msg_id索引后，就已經(jīng)檢索出了34w行，并且由于msg_id的查詢條件是大于等于，因此，再這個(gè)查詢條件后，就不能再用到to_id的索引。

然后再看key_len長(zhǎng)度為16，結(jié)合 key為PRIMARY，那么可以分析得知，只有一個(gè)主鍵索引被用到。

最后看看 type 值，是range，那么就說(shuō)明這個(gè)查詢要么是范圍查詢，要么就是多值匹配。

請(qǐng)注意，from_id != xxx這樣的語(yǔ)句，是無(wú)法用到索引的。只有from_id = xxx就可以用到所以，因此from id 的索引其實(shí)可以不用，建立索引的時(shí)候就要考慮清楚

如何優(yōu)化

既然知道索引不合理，那么就要分析并調(diào)整索引。一般而言，我們既然要從單表里面查詢，那么就需要能夠知道大體，單表里面大致會(huì)有哪些數(shù)據(jù)，現(xiàn)在的量級(jí)大概是多少。

然后開(kāi)始下一步的分析，既然msgid是被設(shè)置為了主鍵，那一定是全局唯一的，所有，有多少數(shù)據(jù)量就至少會(huì)有多少條msgid；那么檢索msg_id基本就是檢索整個(gè)表了。

我們要做的優(yōu)化就是要盡量減少索引，減少查詢的行數(shù)；那么就需要思考，通過(guò)查詢哪些字段才能夠減少行數(shù)？

比如，一個(gè)張表里面，所屬某個(gè)用戶的數(shù)據(jù)，會(huì)不會(huì)比查詢msgid的行數(shù)要少？查詢某個(gè)用戶并且是屬于某個(gè)圈子的，那會(huì)不會(huì)就更少了？等等。

然后根據(jù)實(shí)際情況分析，單表里面命中to_id 的行數(shù)應(yīng)該是會(huì)小于命中msg_id的，因此要首先保證能夠使用到to_id的索引，為此，可以設(shè)置主鍵的時(shí)候把msg_id和to_id的順序交互一下；

但是，由于已經(jīng)是線上的表，已經(jīng)有了大量數(shù)據(jù)，并且業(yè)務(wù)開(kāi)始運(yùn)行，這種情況下，修改主鍵會(huì)引發(fā)很多問(wèn)題（當(dāng)然修改索引是OK的），因此，不建議直接修改主鍵。

那么，為了保證有效使用to_id的索引，就要新建一個(gè)聯(lián)合索引；那么新建的聯(lián)合索引的第一索引字段必然是to_id，針對(duì)此業(yè)務(wù)場(chǎng)景，最好能夠再加上circle_id索引，這樣可以快速索引；

這樣就得到了新的聯(lián)合索引(to_id,circle_id)的索引，然后，因?yàn)橐襪sg_id，為此，在此基礎(chǔ)上，再加上msg_id。

最終得到的聯(lián)合索引為(to_id,circle_id,msg_id)；這樣的話，就能夠快速檢索這樣的查詢語(yǔ)句了：where to_id = xxx and circle_id = xxx and msgId >= xxx

當(dāng)然，索引的建立，也不是說(shuō)某個(gè)sql 語(yǔ)句需要啥索引，就建立某個(gè)聯(lián)合索引，這樣的話，索引太多的話，寫(xiě)的性能受影響（插入、刪除、修改），然后存儲(chǔ)空間也會(huì)相應(yīng)增大；

另外mysql在運(yùn)行時(shí)也會(huì)消耗資源維護(hù)索引，所以，索引并不是越多越好，需要結(jié)合查詢最頻繁、最影響性能的sql來(lái)建立合適的索引。需要再說(shuō)明的是，一個(gè)聯(lián)合索引或者一組主鍵就是一個(gè)btree，多個(gè)索引就是多個(gè)btree

總結(jié)

首先我們需要深入理解索引的原理和實(shí)現(xiàn)，當(dāng)理解了原理后，才能夠更有助于我們建立合適的索引。然后我們建立索引的時(shí)候，不要想當(dāng)然，要先想清楚業(yè)務(wù)邏輯，再建立對(duì)應(yīng)的表結(jié)構(gòu)和索引。

需要再次強(qiáng)調(diào)如下幾點(diǎn):

• 索引不是越多越好

• 區(qū)分主鍵和索引

• 理解索引結(jié)構(gòu)原理

• 理解查詢索引規(guī)則

參考

http://blog.codinglabs.org/articles/theory-of-mysql-index.html

https://tech.meituan.com/2014/06/30/mysql-index.html

作者：吳德寶AllenWu

juejin.im/post/5a6873fbf265da3e393a97fa

總結(jié)

以上是生活随笔為你收集整理的MySQL索引和SQL调优手册的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。