硬干貨：深入剖析 MySQL 索引和 SQL 調(diào)優(yōu)實(shí)戰(zhàn)
你知道的越多，不知道的就越多，業(yè)余的像一棵小草！
你來(lái)，我們一起精進(jìn)！你不來(lái)，我和你的競(jìng)爭(zhēng)對(duì)手一起精進(jìn)！
編輯：業(yè)余草
juejin.cn/post/6844903555141206030
推薦：https://www.xttblog.com/?p=5178
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開頭的單詞呢？或者ze開頭的單詞呢？是不是覺(jué)得如果沒(méi)有索引，這個(gè)事情根本無(wú)法完成？
咱們?nèi)D書館借書也是一樣，如果你要借某一本書，一定是先找到對(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ì)想到搜索樹，其平均復(fù)雜度是lgN，具有不錯(cuò)的查詢性能。
但這里我們忽略了一個(gè)關(guān)鍵的問(wèn)題，復(fù)雜度模型是基于每次相同的操作成本來(lái)考慮的，數(shù)據(jù)庫(kù)實(shí)現(xiàn)比較復(fù)雜，數(shù)據(jù)保存在磁盤上，而為了提高性能，每次又可以把部分?jǐn)?shù)據(jù)讀入內(nèi)存來(lái)計(jì)算，因?yàn)槲覀冎涝L問(wèn)磁盤的成本大概是訪問(wèn)內(nèi)存的十萬(wàn)倍左右，所以簡(jiǎn)單的搜索樹難以滿足復(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í)把磁盤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+樹的查找過(guò)程
如圖所示，如果要查找數(shù)據(jù)項(xiàng)29，那么首先會(huì)把磁盤塊1由磁盤加載到內(nèi)存，此時(shí)發(fā)生一次IO，在內(nèi)存中用二分查找確定29在17和35之間，鎖定磁盤塊1的P2指針，內(nèi)存時(shí)間因?yàn)榉浅６蹋ㄏ啾却疟P的IO）可以忽略不計(jì)
通過(guò)磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內(nèi)存，發(fā)生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針
通過(guò)指針加載磁盤塊8到內(nèi)存，發(fā)生第三次IO，同時(shí)內(nèi)存中做二分查找找到29，結(jié)束查詢，總計(jì)三次IO。
真實(shí)的情況是，3層的b+樹可以表示上百萬(wàn)的數(shù)據(jù)，如果上百萬(wàn)的數(shù)據(jù)查找只需要三次IO，性能提高將是巨大的
如果沒(méi)有索引，每個(gè)數(shù)據(jù)項(xiàng)都要發(fā)生一次IO，那么總共需要百萬(wàn)次的IO，顯然成本非常非常高。
b+樹性質(zhì)
1、通過(guò)上面的分析，我們知道間越小，數(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ù)是按照從左到右的順序來(lái)建立搜索樹的，比如當(dāng)(張三,20,F)這樣的數(shù)據(jù)來(lái)檢索的時(shí)候，b+樹會(huì)優(yōu)先比較name來(lái)確定下一步的所搜方向，如果name相同再依次比較age和sex，最后得到檢索的數(shù)據(jù)
但當(dāng)(20,F)這樣的沒(méi)有name的數(shù)據(jù)來(lái)的時(shí)候，b+樹就不知道下一步該查哪個(gè)節(jié)點(diǎn)，因?yàn)榻⑺阉鳂涞臅r(shí)候name就是第一個(gè)比較因子，必須要先根據(jù)name來(lái)搜索才能知道下一步去哪里查詢。
比如當(dāng)(張三,F)這樣的數(shù)據(jù)來(lái)檢索時(shí)，b+樹可以用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)，這棵樹的葉節(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è)有序元組
索引匹配的最左原則具體是說(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è)或磁盤頁(yè)）的各條數(shù)據(jù)記錄按主鍵順序存放
因此每當(dāng)有一條新的記錄插入時(shí)，MySQL會(huì)根據(jù)其主鍵將其插入適當(dāng)?shù)墓?jié)點(diǎn)和位置，如果頁(yè)面達(dá)到裝載因子（InnoDB默認(rèn)為15/16），則開辟一個(gè)新的頁(yè)（節(jié)點(diǎn)）。
如果表使用自增主鍵，那么每次插入新的記錄，記錄就會(huì)順序添加到當(dāng)前索引節(jié)點(diǎn)的后續(xù)位置，當(dāng)一頁(yè)寫滿，就會(huì)自動(dòng)開辟一個(gè)新的頁(yè)。如下：
這樣就會(huì)形成一個(gè)緊湊的索引結(jié)構(gòu)，近似順序填滿。由于每次插入時(shí)也不需要移動(dòng)已有數(shù)據(jù)，因此效率很高，也不會(huì)增加很多開銷在維護(hù)索引上。
如果使用非自增主鍵（如果身份證號(hào)或?qū)W號(hào)等），由于每次插入主鍵的值近似于隨機(jī)，因此每次新紀(jì)錄都要被插到現(xiàn)有索引頁(yè)得中間某個(gè)位置，如下：
此時(shí)MySQL不得不為了將新記錄插到合適位置而移動(dòng)數(shù)據(jù)，甚至目標(biāo)頁(yè)面可能已經(jīng)被回寫到磁盤上而從緩存中清掉
此時(shí)又要從磁盤上讀回來(lá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" 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ù)據(jù)表中的字段值，但進(jìn)行檢索時(shí)，需要把所有元素都應(yīng)用函數(shù)才能比較，顯然成本太大。所以語(yǔ)句應(yīng)該寫成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ì)有專門的DBA來(lái)處理，但是對(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)橐环矫婺阆胱屗髞?lái)提高性能，另一方面你想讓它更小來(lái)使得崩潰后更快恢復(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)?？吹健甌oo many connections'錯(cuò)誤，是因?yàn)閙ax_connections的值太低了。這非常常見因?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í)回收磁盤空間。
這對(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ì)于磁盤（讀寫）速度較慢的系統(tǒng)，它會(huì)帶來(lá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ù)和日志寫入硬盤的方式。一般來(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操作?？纯碔nnodb_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并且還沒(méi)有發(fā)現(xiàn)任何問(wèn)題，query cache可能對(duì)你有用。這是如果你想停用它，那就得小心了。
log_bin
如果你想讓數(shù)據(jù)庫(kù)服務(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 來(lái)清除舊文件，或者設(shè)置 expire_logs_days 來(lái)指定過(guò)多少天日志將被自動(dòng)清除。
記錄二進(jìn)制日志不是沒(mé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可以開啟慢查詢?nèi)罩?，尤其是線上系統(tǒng)，一般都會(huì)開啟慢查詢?nèi)罩荆绻新樵儯梢酝ㄟ^(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ù)最小的表開始查起，單表每個(gè)字段分別查詢，看哪個(gè)字段的區(qū)分度最高
explain查看執(zhí)行計(jì)劃，是否與1預(yù)期一致（從鎖定記錄較少的表開始查詢）
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ì)開慢查詢?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的基于開銷的優(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操作，其他操作要重寫為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í)大概是多少。
然后開始下一步的分析，既然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ù)開始運(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)合索引，這樣的話，索引太多的話，寫的性能受影響（插入、刪除、修改），然后存儲(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ī)則