MySQL索引

MySQL支持諸多存儲(chǔ)引擎，而各種存儲(chǔ)引擎對(duì)索引的支持也各不相同，因此MySQL數(shù)據(jù)庫支持多種索引類型，如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開頭的單詞呢?或者ze開頭的單詞呢?是不是覺得如果沒有索引，這個(gè)事情根本無法完成?

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

索引原理

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

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

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

稍有算法基礎(chǔ)的同學(xué)會(huì)想到搜索樹，其平均復(fù)雜度是lgN，具有不錯(cuò)的查詢性能。但這里我們忽略了一個(gè)關(guān)鍵的問題，復(fù)雜度模型是基于每次相同的操作成本來考慮的，數(shù)據(jù)庫實(shí)現(xiàn)比較復(fù)雜，數(shù)據(jù)保存在磁盤上，而為了提高性能，每次又可以把部分?jǐn)?shù)據(jù)讀入內(nèi)存來計(jì)算，因?yàn)槲覀冎涝L問磁盤的成本大概是訪問內(nèi)存的十萬倍左右，所以簡單的搜索樹難以滿足復(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í)很簡單，那就是：每次查找數(shù)據(jù)時(shí)把磁盤IO次數(shù)控制在一個(gè)很小的數(shù)量級(jí)，最好是常數(shù)數(shù)量級(jí)。那么我們就想到如果一個(gè)高度可控的多路搜索樹是否能滿足需求呢?就這樣，b+樹應(yīng)運(yùn)而生。

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

 

 

 

 

淺藍(lán)色的塊我們稱之為一個(gè)磁盤塊，可以看到每個(gè)磁盤塊包含幾個(gè)數(shù)據(jù)項(xiàng)(深藍(lán)色所示)和指針(黃色所示)，如磁盤塊1包含數(shù)據(jù)項(xiàng)17和35，包含指針P1、P2、P3，P1表示小于17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大于35的磁盤塊。真實(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ù)據(jù)項(xiàng)29，那么首先會(huì)把磁盤塊1由磁盤加載到內(nèi)存，此時(shí)發(fā)生一次IO，在內(nèi)存中用二分查找確定29在17和35之間，鎖定磁盤塊1的P2指針，內(nèi)存時(shí)間因?yàn)榉浅６?相比磁盤的IO)可以忽略不計(jì)，通過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內(nèi)存，發(fā)生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，通過指針加載磁盤塊8到內(nèi)存，發(fā)生第三次IO，同時(shí)內(nèi)存中做二分查找找到29，結(jié)束查詢，總計(jì)三次IO。

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

b+樹性質(zhì)

1、通過上面的分析，我們知道間越小，數(shù)據(jù)項(xiàng)的數(shù)量越多，樹的高度越低。這就是為什么每個(gè)數(shù)據(jù)項(xiàng)，即索引字段要盡量的小，比如int占4字節(jié)，要比bigint8字節(jié)少一半。這也是為什么b+樹要求把真實(shí)的數(shù)據(jù)放到葉子節(jié)點(diǎn)而不是內(nèi)層節(jié)點(diǎn)，一旦放到內(nèi)層節(jié)點(diǎn)，磁盤塊的數(shù)據(jù)項(xiàng)會(huì)大幅度下降，導(dǎo)致樹增高。當(dāng)數(shù)據(jù)項(xiàng)等于1時(shí)將會(huì)退化成線性表。

2、當(dāng)b+樹的數(shù)據(jù)項(xiàng)是復(fù)合的數(shù)據(jù)結(jié)構(gòu)，比如(name,age,sex)的時(shí)候，b+數(shù)是按照從左到右的順序來建立搜索樹的，比如當(dāng)(張三,20,F)這樣的數(shù)據(jù)來檢索的時(shí)候，b+樹會(huì)優(yōu)先比較name來確定下一步的所搜方向，如果name相同再依次比較age和sex，最后得到檢索的數(shù)據(jù);但當(dāng)(20,F)這樣的沒有name的數(shù)據(jù)來的時(shí)候，b+樹就不知道下一步該查哪個(gè)節(jié)點(diǎn)，因?yàn)榻⑺阉鳂涞臅r(shí)候name就是第一個(gè)比較因子，必須要先根據(jù)name來搜索才能知道下一步去哪里查詢。

比如當(dāng)(張三,F)這樣的數(shù)據(jù)來檢索時(shí)，b+樹可以用name來指定搜索方向，但下一個(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)示意圖?？梢钥闯鯩yISAM的索引文件僅僅保存數(shù)據(jù)記錄的地址。在MyISAM中，主索引和輔助索引(Secondary key)在結(jié)構(gòu)上沒有任何區(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)，這棵樹的葉節(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可以沒有)，如果沒有顯式指定，則MySQL系統(tǒng)會(huì)自動(dòng)選擇一個(gè)可以唯一標(biāo)識(shí)數(shù)據(jù)記錄的列作為主鍵，如果不存在這種列，則MySQL自動(dòng)為InnoDB表生成一個(gè)隱含字段作為主鍵，這個(gè)字段長度為6個(gè)字節(jié)，類型為長整形。

第二個(gè)與MyISAM索引的不同是InnoDB的輔助索引data域存儲(chǔ)相應(yīng)記錄主鍵的值而不是地址。換句話說，InnoDB的所有輔助索引都引用主鍵作為data域。例如，下圖為定義在Col3上的一個(gè)輔助索引：

 

 

 

 

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

了解不同存儲(chǔ)引擎的索引實(shí)現(xiàn)方式對(duì)于正確使用和優(yōu)化索引都非常有幫助，例如知道了InnoDB的索引實(shí)現(xiàn)后，就很容易明白為什么不建議使用過長的字段作為主鍵，因?yàn)樗休o助索引都引用主索引，過長的主索引會(huì)令輔助索引變得過大。再例如，用非單調(diào)的字段作為主鍵在InnoDB中不是個(gè)好主意，因?yàn)镮nnoDB數(shù)據(jù)文件本身是一顆B+Tree，非單調(diào)的主鍵會(huì)造成在插入新記錄時(shí)數(shù)據(jù)文件為了維持B+Tree的特性而頻繁的分裂調(diào)整，十分低效，而使用自增字段作為主鍵則是一個(gè)很好的選擇。

如何建立合適的索引

建立索引的原理

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

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

• 那么查詢的時(shí)候，如果查詢【A】【A，B】 【A，B，C】，那么可以通過索引查詢
• 如果查詢的時(shí)候，采用【A，C】，那么C這個(gè)雖然是索引，但是由于中間缺失了B，因此C這個(gè)索引是用不到的，只能用到A索引
• 如果查詢的時(shí)候，采用【B】 【B，C】 【C】，由于沒有用到第一列索引，不是最左前綴，那么后面的索引也是用不到了
• 如果查詢的時(shí)候，采用范圍查詢，并且是最左前綴，也就是第一列索引，那么可以用到索引，但是范圍后面的列無法用到索引

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

在使用InnoDB存儲(chǔ)引擎時(shí)，如果沒有特別的需要，請(qǐng)永遠(yuǎn)使用一個(gè)與業(yè)務(wù)無關(guān)的自增字段作為主鍵。如果從數(shù)據(jù)庫索引優(yōu)化角度看，使用InnoDB引擎而不使用自增主鍵絕對(duì)是一個(gè)糟糕的主意。

InnoDB使用聚集索引，數(shù)據(jù)記錄本身被存于主索引(一顆B+Tree)的葉子節(jié)點(diǎn)上。這就要求同一個(gè)葉子節(jié)點(diǎn)內(nèi)(大小為一個(gè)內(nèi)存頁或磁盤頁)的各條數(shù)據(jù)記錄按主鍵順序存放，因此每當(dāng)有一條新的記錄插入時(shí)，MySQL會(huì)根據(jù)其主鍵將其插入適當(dāng)?shù)墓?jié)點(diǎn)和位置，如果頁面達(dá)到裝載因子(InnoDB默認(rèn)為15/16)，則開辟一個(gè)新的頁(節(jié)點(diǎn))。如果表使用自增主鍵，那么每次插入新的記錄，記錄就會(huì)順序添加到當(dāng)前索引節(jié)點(diǎn)的后續(xù)位置，當(dāng)一頁寫滿，就會(huì)自動(dòng)開辟一個(gè)新的頁。如下：

 

 

 

 

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

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

 

 

 

 

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

因此，只要可以，請(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ì)問，這個(gè)比例有什么經(jīng)驗(yàn)值嗎?使用場(chǎng)景不同，這個(gè)值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃描10條記錄

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

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

MySQL優(yōu)化

配置優(yōu)化

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

基本配置

innodb_buffer_pool_size

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

innodb_log_file_size

這是redo日志的大小。redo日志被用于確保寫操作快速而可靠并且在崩潰時(shí)恢復(fù)。一直到MySQL 5.1，它都難于調(diào)整，因?yàn)橐环矫婺阆胱屗髞硖岣咝阅埽硪环矫婺阆胱屗硎沟帽罎⒑蟾旎謴?fù)。

幸運(yùn)的是從MySQL 5.5之后，崩潰恢復(fù)的性能的到了很大提升，這樣你就可以同時(shí)擁有較高的寫入性能和崩潰恢復(fù)性能了。一直到MySQL 5.5，redo日志的總尺寸被限定在4GB(默認(rèn)可以有2個(gè)log文件)。這在MySQL 5.6里被提高了。如果你知道你的應(yīng)用程序需要頻繁的寫入數(shù)據(jù)并且你使用的時(shí)MySQL 5.6，你可以一開始就把它這是成4G。

max_connections

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

max_connection值被設(shè)高了(例如1000或更高)之后一個(gè)主要缺陷是當(dāng)服務(wù)器運(yùn)行1000個(gè)或更高的活動(dòng)事務(wù)時(shí)會(huì)變的沒有響應(yīng)。在應(yīng)用程序里使用連接池或者在MySQL里使用進(jì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í)回收磁盤空間。

這對(duì)于一些高級(jí)特性也是有必要的，比如數(shù)據(jù)壓縮。但是它不會(huì)帶來任何性能收益。你不想讓每張表一個(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ì)于磁盤(讀寫)速度較慢的系統(tǒng)，它會(huì)帶來很巨大的開銷，因?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ù)和日志寫入硬盤的方式。一般來說，如果你有硬件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)一般來說已經(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)是將其從一開始就停用，設(shè)置query_cache_size = 0(現(xiàn)在MySQL 5.6的默認(rèn)值)并利用其他方法加速查詢：優(yōu)化索引、增加拷貝分散負(fù)載或者啟用額外的緩存(比如memcache或redis)。

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

log_bin

如果你想讓數(shù)據(jù)庫服務(wù)器充當(dāng)主節(jié)點(diǎn)的備份節(jié)點(diǎn)，那么開啟二進(jìn)制日志是必須的。如果這么做了之后，還別忘了設(shè)置server_id為一個(gè)唯一的值。就算只有一個(gè)服務(wù)器，如果你想做基于時(shí)間點(diǎn)的數(shù)據(jù)恢復(fù)，這(開啟二進(jìn)制日志)也是很有用的：從你最近的備份中恢復(fù)(全量備份)，并應(yīng)用二進(jìn)制日志中的修改(增量備份)。

二進(jìn)制日志一旦創(chuàng)建就將永久保存。所以如果你不想讓磁盤空間耗盡，你可以用 PURGE BINARY LOGS 來清除舊文件，或者設(shè)置 expire_logs_days 來指定過多少天日志將被自動(dòng)清除。記錄二進(jìn)制日志不是沒有開銷的，所以如果你在一個(gè)非主節(jié)點(diǎn)的復(fù)制節(jié)點(diǎn)上不需要它的話，那么建議關(guān)閉這個(gè)選項(xiàng)。

skip_name_resolve

當(dāng)客戶端連接數(shù)據(jù)庫服務(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語句中只能使用IP地址了，因此在添加這項(xiàng)設(shè)置到一個(gè)已有系統(tǒng)中必須格外小心。

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

一般要進(jìn)行SQL調(diào)優(yōu)，那么就說有慢查詢的SQL，系統(tǒng)或者server可以開啟慢查詢?nèi)罩荆绕涫蔷€上系統(tǒng)，一般都會(huì)開啟慢查詢?nèi)罩?，如果有慢查詢，可以通過日志來過濾。但是知道了有需要優(yōu)化的SQL后，下面要做的就是如何進(jìn)行調(diào)優(yōu)

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

1. 先運(yùn)行看看是否真的很慢，注意設(shè)置SQL_NO_CACHE
2. where條件單表查，鎖定最小返回記錄表。這句話的意思是把查詢語句的where都應(yīng)用到表中返回的記錄數(shù)最小的表開始查起，單表每個(gè)字段分別查詢，看哪個(gè)字段的區(qū)分度最高
3. explain查看執(zhí)行計(jì)劃，是否與1預(yù)期一致(從鎖定記錄較少的表開始查詢)
4. order by limit 形式的sql語句讓排序的表優(yōu)先查
5. 了解業(yè)務(wù)方使用場(chǎng)景
6. 加索引時(shí)參照建索引的幾大原則
7. 觀察結(jié)果，不符合預(yù)期繼續(xù)從0分析

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

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

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

所以我們深入了解MySQL的基于開銷的優(yōu)化器，還可以獲得很多可能被優(yōu)化器考慮到的訪問策略的細(xì)節(jié)，以及當(dāng)運(yùn)行SQL語句時(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) 

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

• id : 表示SQL執(zhí)行的順序的標(biāo)識(shí),SQL從大到小的執(zhí)行
• select_type：表示查詢中每個(gè)select子句的類型
• table：顯示這一行的數(shù)據(jù)是關(guān)于哪張表的，有時(shí)不是真實(shí)的表名字
• type：表示MySQL在表中找到所需行的方式，又稱“訪問類型”。常用的類型有：ALL, index, range, ref, eq_ref, const, system, NULL(從左到右，性能從差到好)
• possible_keys：指出MySQL能使用哪個(gè)索引在表中找到記錄，查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用
• Key：key列顯示MySQL實(shí)際決定使用的鍵(索引)，如果沒有選擇索引，鍵是NULL。
• key_len：表示索引中使用的字節(jié)數(shù)，可通過該列計(jì)算查詢中使用的索引的長度(key_len顯示的值為索引字段的最大可能長度，并非實(shí)際使用長度，即key_len是根據(jù)表定義計(jì)算而得，不是通過表內(nèi)檢索出的)
• ref：表示上述表的連接匹配條件，即哪些列或常量被用于查找索引列上的值
• rows：表示MySQL根據(jù)表統(tǒng)計(jì)信息及索引選用情況，估算的找到所需的記錄所需要讀取的行數(shù)，理論上行數(shù)越少，查詢性能越好
• Extra：該列包含MySQL解決查詢的詳細(xì)信息

EXPLAIN的特性

• EXPLAIN不會(huì)告訴你關(guān)于觸發(fā)器、存儲(chǔ)過程的信息或用戶自定義函數(shù)對(duì)查詢的影響情況
• EXPLAIN不考慮各種Cache
• EXPLAIN不能顯示MySQL在執(zhí)行查詢時(shí)所作的優(yōu)化工作
• 部分統(tǒng)計(jì)信息是估算的，并非精確值
• EXPALIN只能解釋SELECT操作，其他操作要重寫為SELECT后查看執(zhí)行計(jì)劃。

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

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

假如有如下表結(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 

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

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) 

問題分析

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

分析這個(gè)執(zhí)行計(jì)劃可以看到，當(dāng)包含msg_id >= xxx 查詢條件的時(shí)候，rows有34w多行，這種情況，說明檢索太多，要么就是表里面確實(shí)有這么大，要么就是索引不合理沒有用到索引，大都情況是沒用合理用到索引。列中所用到的索引也是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長度為16，結(jié)合 key為PRIMARY，那么可以分析得知，只有一個(gè)主鍵索引被用到。

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

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

如何優(yōu)化

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

然后開始下一步的分析，既然msgid是被設(shè)置為了主鍵，那一定是全局唯一的，所有，有多少數(shù)據(jù)量就至少會(huì)有多少條msgid;那么檢索msg_id基本就是檢索整個(gè)表了。我們要做的優(yōu)化就是要盡量減少索引，減少查詢的行數(shù);那么就需要思考，通過查詢哪些字段才能夠減少行數(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ù)開始運(yùn)行，這種情況下，修改主鍵會(huì)引發(fā)很多問題(當(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);這樣的話，就能夠快速檢索這樣的查詢語句了：where to_id = xxx and circle_id = xxx and msgId >= xxx

當(dāng)然，索引的建立，也不是說某個(gè)sql 語句需要啥索引，就建立某個(gè)聯(lián)合索引，這樣的話，索引太多的話，寫的性能受影響(插入、刪除、修改)，然后存儲(chǔ)空間也會(huì)相應(yīng)增大;另外mysql在運(yùn)行時(shí)也會(huì)消耗資源維護(hù)索引，所以，索引并不是越多越好，需要結(jié)合查詢最頻繁、最影響性能的sql來建立合適的索引。需要再說明的是，一個(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