MySQL優化原理

說起MySQL的查詢優化，相信大家收藏了一堆奇技淫巧：不能使用SELECT *、不使用NULL欄位、合理創建索引、為欄位選擇合適的資料型別..... 你是否真的理解這些優化技巧？是否理解其背后的作業原理？在實際場景下性能真有提升嗎？我想未必，因而理解這些優化建議背后的原理就尤為重要，希望本文能讓你重新審視這些優化建議，并在實際業務場景下合理的運用，

MySQL邏輯架構

如果能在頭腦中構建一幅MySQL各組件之間如何協同作業的架構圖，有助于深入理解MySQL服務器，下圖展示了MySQL的邏輯架構圖，

MySQL邏輯架構整體分為三層，最上層為客戶端層，并非MySQL所獨有，諸如：連接處理、授權認證、安全等功能均在這一層處理，

MySQL大多數核心服務均在中間這一層，包括查詢決議、分析、優化、快取、內置函式(比如：時間、數學、加密等函式)，所有的跨存盤引擎的功能也在這一層實作：存盤程序、觸發器、視圖等，

最下層為存盤引擎，其負責MySQL中的資料存盤和提取，和Linux下的檔案系統類似，每種存盤引擎都有其優勢和劣勢，中間的服務層通過API與存盤引擎通信，這些API介面屏蔽了不同存盤引擎間的差異，

MySQL查詢程序

我們總是希望MySQL能夠獲得更高的查詢性能，最好的辦法是弄清楚MySQL是如何優化和執行查詢的，一旦理解了這一點，就會發現：很多的查詢優化作業實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式運行而已，

當向MySQL發送一個請求的時候，MySQL到底做了些什么呢？

客戶端/服務端通信協議

MySQL客戶端/服務端通信協議是“半雙工”的：在任一時刻，要么是服務器向客戶端發送資料，要么是客戶端向服務器發送資料，這兩個動作不能同時發生，一旦一端開始發送訊息，另一端要接收完整個訊息才能回應它，所以我們無法也無須將一個訊息切成小塊獨立發送，也沒有辦法進行流量控制，

客戶端用一個單獨的資料包將查詢請求發送給服務器，所以當查詢陳述句很長的時候，需要設定max_allowed_packet引數，但是需要注意的是，如果查詢實在是太大，服務端會拒絕接收更多資料并拋出例外，

與之相反的是，服務器回應給用戶的資料通常會很多，由多個資料包組成，但是當服務器回應客戶端請求時，客戶端必須完整的接收整個回傳結果，而不能簡單的只取前面幾條結果，然后讓服務器停止發送，因而在實際開發中，盡量保持查詢簡單且只回傳必需的資料，減小通信間資料包的大小和數量是一個非常好的習慣，這也是查詢中盡量避免使用SELECT *以及加上LIMIT限制的原因之一，

查詢快取

在決議一個查詢陳述句前，如果查詢快取是打開的，那么MySQL會檢查這個查詢陳述句是否命中查詢快取中的資料，如果當前查詢恰好命中查詢快取，在檢查一次用戶權限后直接回傳快取中的結果，這種情況下，查詢不會被決議，也不會生成執行計劃，更不會執行，

MySQL將快取存放在一個參考表（不要理解成table，可以認為是類似于HashMap的資料結構），通過一個哈希值索引，這個哈希值通過查詢本身、當前要查詢的資料庫、客戶端協議版本號等一些可能影響結果的資訊計算得來，所以兩個查詢在任何字符上的不同（例如：空格、注釋），都會導致快取不會命中，

如果查詢中包含任何用戶自定義函式、存盤函式、用戶變數、臨時表、MySQL庫中的系統表，其查詢結果都不會被快取，比如函式NOW()或者CURRENT_DATE()會因為不同的查詢時間，回傳不同的查詢結果，再比如包含CURRENT_USER或者CONNECION_ID()的查詢陳述句會因為不同的用戶而回傳不同的結果，將這樣的查詢結果快取起來沒有任何的意義，

既然是快取，就會失效，那查詢快取何時失效呢？MySQL的查詢快取系統會跟蹤查詢中涉及的每個表，如果這些表（資料或結構）發生變化，那么和這張表相關的所有快取資料都將失效，正因為如此，在任何的寫操作時，MySQL必須將對應表的所有快取都設定為失效，如果查詢快取非常大或者碎片很多，這個操作就可能帶來很大的系統消耗，甚至導致系統僵死一會兒，而且查詢快取對系統的額外消耗也不僅僅在寫操作，讀操作也不例外：

1. 任何的查詢陳述句在開始之前都必須經過檢查，即使這條SQL陳述句永遠不會命中快取

2. 如果查詢結果可以被快取，那么執行完成后，會將結果存入快取，也會帶來額外的系統消耗

基于此，我們要知道并不是什么情況下查詢快取都會提高系統性能，快取和失效都會帶來額外消耗，只有當快取帶來的資源節約大于其本身消耗的資源時，才會給系統帶來性能提升，但要如何評估打開快取是否能夠帶來性能提升是一件非常困難的事情，也不在本文討論的范疇內，如果系統確實存在一些性能問題，可以嘗試打開查詢快取，并在資料庫設計上做一些優化，比如：

1. 用多個小表代替一個大表，注意不要過度設計

2. 批量插入代替回圈單條插入

3. 合理控制快取空間大小，一般來說其大小設定為幾十兆比較合適

4. 可以通過SQL_CACHE和SQL_NO_CACHE來控制某個查詢陳述句是否需要進行快取

最后的忠告是不要輕易打開查詢快取，特別是寫密集型應用，如果你實在是忍不住，可以將query_cache_type設定為DEMAND，這時只有加入SQL_CACHE的查詢才會走快取，其他查詢則不會，這樣可以非常自由地控制哪些查詢需要被快取，

當然查詢快取系統本身是非常復雜的，這里討論的也只是很小的一部分，其他更深入的話題，比如：快取是如何使用記憶體的？如何控制記憶體的碎片化？事務對查詢快取有何影響等等，讀者可以自行閱讀相關資料，這里權當拋磚引玉吧，

語法決議和預處理

MySQL通過關鍵字將SQL陳述句進行決議，并生成一顆對應的決議樹，這個程序決議器主要通過語法規則來驗證和決議，比如SQL中是否使用了錯誤的關鍵字或者關鍵字的順序是否正確等等，預處理則會根據MySQL規則進一步檢查決議樹是否合法，比如檢查要查詢的資料表和資料列是否存在等，

查詢優化

經過前面的步驟生成的語法樹被認為是合法的了，并且由優化器將其轉化成查詢計劃，多數情況下，一條查詢可以有很多種執行方式，最后都回傳相應的結果，優化器的作用就是找到這其中最好的執行計劃，

MySQL使用基于成本的優化器，它嘗試預測一個查詢使用某種執行計劃時的成本，并選擇其中成本最小的一個，在MySQL可以通過查詢當前會話的last_query_cost的值來得到其計算當前查詢的成本，

mysql> select * from t_message limit 10;
...省略結果集

mysql> show status like 'last_query_cost';
+-----------------+-------------+
| Variable_name   | Value       |
+-----------------+-------------+
| Last_query_cost | 6391.799000 |
+-----------------+-------------+

示例中的結果表示優化器認為大概需要做6391個資料頁的隨機查找才能完成上面的查詢，這個結果是根據一些列的統計資訊計算得來的，這些統計資訊包括：每張表或者索引的頁面個數、索引的基數、索引和資料行的長度、索引的分布情況等等，

有非常多的原因會導致MySQL選擇錯誤的執行計劃，比如統計資訊不準確、不會考慮不受其控制的操作成本（用戶自定義函式、存盤程序）、MySQL認為的最優跟我們想的不一樣（我們希望執行時間盡可能短，但MySQL值選擇它認為成本小的，但成本小并不意味著執行時間短）等等，

MySQL的查詢優化器是一個非常復雜的部件，它使用了非常多的優化策略來生成一個最優的執行計劃：

• 重新定義表的關聯順序（多張表關聯查詢時，并不一定按照SQL中指定的順序進行，但有一些技巧可以指定關聯順序）

• 優化MIN()和MAX()函式（找某列的最小值，如果該列有索引，只需要查找B+Tree索引最左端，反之則可以找到最大值，具體原理見下文）

• 提前終止查詢（比如：使用Limit時，查找到滿足數量的結果集后會立即終止查詢）

• 優化排序（在老版本MySQL會使用兩次傳輸排序，即先讀取行指標和需要排序的欄位在記憶體中對其排序，然后再根據排序結果去讀取資料行，而新版本采用的是單次傳輸排序，也就是一次讀取所有的資料行，然后根據給定的列排序，對于I/O密集型應用，效率會高很多）

隨著MySQL的不斷發展，優化器使用的優化策略也在不斷的進化，這里僅僅介紹幾個非常常用且容易理解的優化策略，其他的優化策略，大家自行查閱吧，

查詢執行引擎

在完成決議和優化階段以后，MySQL會生成對應的執行計劃，查詢執行引擎根據執行計劃給出的指令逐步執行得出結果，整個執行程序的大部分操作均是通過呼叫存盤引擎實作的介面來完成，這些介面被稱為handler API，查詢程序中的每一張表由一個handler實體表示，實際上，MySQL在查詢優化階段就為每一張表創建了一個handler實體，優化器可以根據這些實體的介面來獲取表的相關資訊，包括表的所有列名、索引統計資訊等，存盤引擎介面提供了非常豐富的功能，但其底層僅有幾十個介面，這些介面像搭積木一樣完成了一次查詢的大部分操作，

回傳結果給客戶端

查詢執行的最后一個階段就是將結果回傳給客戶端，即使查詢不到資料，MySQL仍然會回傳這個查詢的相關資訊，比如該查詢影響到的行數以及執行時間等，

如果查詢快取被打開且這個查詢可以被快取，MySQL也會將結果存放到快取中，

結果集回傳客戶端是一個增量且逐步回傳的程序，有可能MySQL在生成第一條結果時，就開始向客戶端逐步回傳結果集了，這樣服務端就無須存盤太多結果而消耗過多記憶體，也可以讓客戶端第一時間獲得回傳結果，需要注意的是，結果集中的每一行都會以一個滿足①中所描述的通信協議的資料包發送，再通過TCP協議進行傳輸，在傳輸程序中，可能對MySQL的資料包進行快取然后批量發送，

回頭總結一下MySQL整個查詢執行程序，總的來說分為6個步驟：

• 客戶端向MySQL服務器發送一條查詢請求

• 服務器首先檢查查詢快取，如果命中快取，則立刻回傳存盤在快取中的結果，否則進入下一階段

• 服務器進行SQL決議、預處理、再由優化器生成對應的執行計劃

• MySQL根據執行計劃，呼叫存盤引擎的API來執行查詢

• 將結果回傳給客戶端，同時快取查詢結果

性能優化建議

看了這么多，你可能會期待給出一些優化手段，是的，下面會從3個不同方面給出一些優化建議，但請等等，還有一句忠告要先送給你：不要聽信你看到的關于優化的“絕對真理”，包括本文所討論的內容，而應該是在實際的業務場景下通過測驗來驗證你關于執行計劃以及回應時間的假設，

Scheme設計與資料型別優化

選擇資料型別只要遵循小而簡單的原則就好，越小的資料型別通常會更快，占用更少的磁盤、記憶體，處理時需要的CPU周期也更少，越簡單的資料型別在計算時需要更少的CPU周期，比如，整型就比字符操作代價低，因而會使用整型來存盤ip地址，使用DATETIME來存盤時間，而不是使用字串，

這里總結幾個可能容易理解錯誤的技巧：

1. 通常來說把可為NULL的列改為NOT NULL不會對性能提升有多少幫助，只是如果計劃在列上創建索引，就應該將該列設定為NOT NULL，

2. 對整數型別指定寬度，比如INT(11)，沒有任何卵用，INT使用32位（4個位元組）存盤空間，那么它的表示范圍已經確定，所以INT(1)和INT(20)對于存盤和計算是相同的，

3. UNSIGNED表示不允許負值，大致可以使正數的上限提高一倍，比如TINYINT存盤范圍是-128 ~ 127，而UNSIGNED TINYINT存盤的范圍卻是0 - 255，

4. 通常來講，沒有太大的必要使用DECIMAL資料型別，即使是在需要存盤財務資料時，仍然可以使用BIGINT，比如需要精確到萬分之一，那么可以將資料乘以一百萬然后使用BIGINT存盤，這樣可以避免浮點數計算不準確和DECIMAL精確計算代價高的問題，

5. TIMESTAMP使用4個位元組存盤空間，DATETIME使用8個位元組存盤空間，因而，TIMESTAMP只能表示1970 - 2038年，比DATETIME表示的范圍小得多，而且TIMESTAMP的值因時區不同而不同，

6. 大多數情況下沒有使用列舉型別的必要，其中一個缺點是列舉的字串串列是固定的，添加和洗掉字串（列舉選項）必須使用ALTER TABLE（如果只只是在串列末尾追加元素，不需要重建表），

7. schema的列不要太多，原因是存盤引擎的API作業時需要在服務器層和存盤引擎層之間通過行緩沖格式拷貝資料，然后在服務器層將緩沖內容解碼成各個列，這個轉換程序的代價是非常高的，如果列太多而實際使用的列又很少的話，有可能會導致CPU占用過高，

8. 大表ALTER TABLE非常耗時，MySQL執行大部分修改表結果操作的方法是用新的結構創建一個張空表，從舊表中查出所有的資料插入新表，然后再洗掉舊表，尤其當記憶體不足而表又很大，而且還有很大索引的情況下，耗時更久，當然有一些奇技淫巧可以解決這個問題，有興趣可自行查閱，

創建高性能索引

索引是提高MySQL查詢性能的一個重要途徑，但過多的索引可能會導致過高的磁盤使用率以及過高的記憶體占用，從而影回應用程式的整體性能，應當盡量避免事后才想起添加索引，因為事后可能需要監控大量的SQL才能定位到問題所在，而且添加索引的時間肯定是遠大于初始添加索引所需要的時間，可見索引的添加也是非常有技術含量的，

接下來將向你展示一系列創建高性能索引的策略，以及每條策略其背后的作業原理，但在此之前，先了解與索引相關的一些演算法和資料結構，將有助于更好的理解后文的內容，

索引相關的資料結構和演算法

通常我們所說的索引是指B-Tree索引，它是目前關系型資料庫中查找資料最為常用和有效的索引，大多數存盤引擎都支持這種索引，使用B-Tree這個術語，是因為MySQL在CREATE TABLE或其它陳述句中使用了這個關鍵字，但實際上不同的存盤引擎可能使用不同的資料結構，比如InnoDB就是使用的B+Tree，

B+Tree中的B是指balance，意為平衡，需要注意的是，B+樹索引并不能找到一個給定鍵值的具體行，它找到的只是被查找資料行所在的頁，接著資料庫會把頁讀入到記憶體，再在記憶體中進行查找，最后得到要查找的資料，

在介紹B+Tree前，先了解一下二叉查找樹，它是一種經典的資料結構，其左子樹的值總是小于根的值，右子樹的值總是大于根的值，如下圖①，如果要在這課樹中查找值為5的記錄，其大致流程：先找到根，其值為6，大于5，所以查找左子樹，找到3，而5大于3，接著找3的右子樹，總共找了3次，同樣的方法，如果查找值為8的記錄，也需要查找3次，所以二叉查找樹的平均查找次數為(3 + 3 + 3 + 2 + 2 + 1) / 6 = 2.3次，而順序查找的話，查找值為2的記錄，僅需要1次，但查找值為8的記錄則需要6次，所以順序查找的平均查找次數為：(1 + 2 + 3 + 4 + 5 + 6) / 6 = 3.3次，因此大多數情況下二叉查找樹的平均查找速度比順序查找要快，

由于二叉查找樹可以任意構造，同樣的值，可以構造出如圖②的二叉查找樹，顯然這棵二叉樹的查詢效率和順序查找差不多，若想二叉查找數的查詢性能最高，需要這棵二叉查找樹是平衡的，也即平衡二叉樹（AVL樹），

平衡二叉樹首先需要符合二叉查找樹的定義，其次必須滿足任何節點的兩個子樹的高度差不能大于1，顯然圖②不滿足平衡二叉樹的定義，而圖①是一課平衡二叉樹，平衡二叉樹的查找性能是比較高的（性能最好的是最優二叉樹），查詢性能越好，維護的成本就越大，比如圖①的平衡二叉樹，當用戶需要插入一個新的值9的節點時，就需要做出如下變動，

通過一次左旋操作就將插入后的樹重新變為平衡二叉樹是最簡單的情況了，實際應用場景中可能需要旋轉多次，至此我們可以考慮一個問題，平衡二叉樹的查找效率還不錯，實作也非常簡單，相應的維護成本還能接受，為什么MySQL索引不直接使用平衡二叉樹？

隨著資料庫中資料的增加，索引本身大小隨之增加，不可能全部存盤在記憶體中，因此索引往往以索引檔案的形式存盤的磁盤上，這樣的話，索引查找程序中就要產生磁盤I/O消耗，相對于記憶體存取，I/O存取的消耗要高幾個數量級，可以想象一下一棵幾百萬節點的二叉樹的深度是多少？如果將這么大深度的一顆二叉樹放磁盤上，每讀取一個節點，需要一次磁盤的I/O讀取，整個查找的耗時顯然是不能夠接受的，那么如何減少查找程序中的I/O存取次數？

一種行之有效的解決方法是減少樹的深度，將二叉樹變為m叉樹（多路搜索樹），而B+Tree就是一種多路搜索樹，理解B+Tree時，只需要理解其最重要的兩個特征即可：第一，所有的關鍵字（可以理解為資料）都存盤在葉子節點（Leaf Page），非葉子節點（Index Page）并不存盤真正的資料，所有記錄節點都是按鍵值大小順序存放在同一層葉子節點上，其次，所有的葉子節點由指標連接，如下圖為高度為2的簡化了的B+Tree，

怎么理解這兩個特征？MySQL將每個節點的大小設定為一個頁的整數倍（原因下文會介紹），也就是在節點空間大小一定的情況下，每個節點可以存盤更多的內結點，這樣每個結點能索引的范圍更大更精確，所有的葉子節點使用指標鏈接的好處是可以進行區間訪問，比如上圖中，如果查找大于20而小于30的記錄，只需要找到節點20，就可以遍歷指標依次找到25、30，如果沒有鏈接指標的話，就無法進行區間查找，這也是MySQL使用B+Tree作為索引存盤結構的重要原因，

MySQL為何將節點大小設定為頁的整數倍，這就需要理解磁盤的存盤原理，磁盤本身存取就比主存慢很多，在加上機械運動損耗（特別是普通的機械硬碟），磁盤的存取速度往往是主存的幾百萬分之一，為了盡量減少磁盤I/O，磁盤往往不是嚴格按需讀取，而是每次都會預讀，即使只需要一個位元組，磁盤也會從這個位置開始，順序向后讀取一定長度的資料放入記憶體，預讀的長度一般為頁的整數倍，

頁是計算機管理存盤器的邏輯塊，硬體及OS往往將主存和磁盤存盤區分割為連續的大小相等的塊，每個存盤塊稱為一頁（許多OS中，頁的大小通常為4K），主存和磁盤以頁為單位交換資料，當程式要讀取的資料不在主存中時，會觸發一個缺頁例外，此時系統會向磁盤發出讀盤信號，磁盤會找到資料的起始位置并向后連續讀取一頁或幾頁載入記憶體中，然后一起回傳，程式繼續運行，

MySQL巧妙利用了磁盤預讀原理，將一個節點的大小設為等于一個頁，這樣每個節點只需要一次I/O就可以完全載入，為了達到這個目的，每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存盤在一個頁里，加之計算機存盤分配都是按頁對齊的，就實作了讀取一個節點只需一次I/O，假設B+Tree的高度為h，一次檢索最多需要h-1I/O（根節點常駐記憶體），復雜度$O(h) = O(\log_{M}N)$，實際應用場景中，M通常較大，常常超過100，因此樹的高度一般都比較小，通常不超過3，

最后簡單了解下B+Tree節點的操作，在整體上對索引的維護有一個大概的了解，雖然索引可以大大提高查詢效率，但維護索引仍要花費很大的代價，因此合理的創建索引也就尤為重要，

仍以上面的樹為例，我們假設每個節點只能存盤4個內節點，首先要插入第一個節點28，如下圖所示，

接著插入下一個節點70，在Index Page中查詢后得知應該插入到50 - 70之間的葉子節點，但葉子節點已滿，這時候就需要進行也分裂的操作，當前的葉子節點起點為50，所以根據中間值來拆分葉子節點，如下圖所示，

最后插入一個節點95，這時候Index Page和Leaf Page都滿了，就需要做兩次拆分，如下圖所示，

拆分后最終形成了這樣一顆樹，

B+Tree為了保持平衡，對于新插入的值需要做大量的拆分頁操作，而頁的拆分需要I/O操作，為了盡可能的減少頁的拆分操作，B+Tree也提供了類似于平衡二叉樹的旋轉功能，當Leaf Page已滿但其左右兄弟節點沒有滿的情況下，B+Tree并不急于去做拆分操作，而是將記錄移到當前所在頁的兄弟節點上，通常情況下，左兄弟會被先檢查用來做旋轉操作，就比如上面第二個示例，當插入70的時候，并不會去做頁拆分，而是左旋操作，

通過旋轉操作可以最大限度的減少頁分裂，從而減少索引維護程序中的磁盤的I/O操作，也提高索引維護效率，需要注意的是，洗掉節點跟插入節點類似，仍然需要旋轉和拆分操作，這里就不再說明，

高性能策略

通過上文，相信你對B+Tree的資料結構已經有了大致的了解，但MySQL中索引是如何組織資料的存盤呢？以一個簡單的示例來說明，假如有如下資料表：

CREATE TABLE People(
    last_name varchar(50) not null,
    first_name varchar(50) not null,
    dob date not null,
    gender enum(`m`,`f`) not null,
    key(last_name,first_name,dob)
);

　　對于表中每一行資料，索引中包含了last_name、first_name、dob列的值，下圖展示了索引是如何組織資料存盤的，

可以看到，索引首先根據第一個欄位來排列順序，當名字相同時，則根據第三個欄位，即出生日期來排序，正是因為這個原因，才有了索引的“最左原則”，

1、MySQL不會使用索引的情況：非獨立的列

“獨立的列”是指索引列不能是運算式的一部分，也不能是函式的引數，比如：

select * from where id + 1 = 5

我們很容易看出其等價于 id = 4，但是MySQL無法自動決議這個運算式，使用函式是同樣的道理，

2、前綴索引

如果列很長，通常可以索引開始的部分字符，這樣可以有效節約索引空間，從而提高索引效率，

3、多列索引和索引順序

在多數情況下，在多個列上建立獨立的索引并不能提高查詢性能，理由非常簡單，MySQL不知道選擇哪個索引的查詢效率更好，所以在老版本，比如MySQL5.0之前就會隨便選擇一個列的索引，而新的版本會采用合并索引的策略，舉個簡單的例子，在一張電影演員表中，在actor_id和film_id兩個列上都建立了獨立的索引，然后有如下查詢：

select film_id,actor_id from film_actor where actor_id = 1 or film_id = 1

老版本的MySQL會隨機選擇一個索引，但新版本做如下的優化：

select film_id,actor_id from film_actor where actor_id = 1 

union all

select film_id,actor_id from film_actor where film_id = 1 and actor_id <> 1

• 當出現多個索引做相交操作時（多個AND條件），通常來說一個包含所有相關列的索引要優于多個獨立索引，

• 當出現多個索引做聯合操作時（多個OR條件），對結果集的合并、排序等操作需要耗費大量的CPU和記憶體資源，特別是當其中的某些索引的選擇性不高，需要回傳合并大量資料時，查詢成本更高，所以這種情況下還不如走全表掃描，

因此explain時如果發現有索引合并（Extra欄位出現Using union），應該好好檢查一下查詢和表結構是不是已經是最優的，如果查詢和表都沒有問題，那只能說明索引建的非常糟糕，應當慎重考慮索引是否合適，有可能一個包含所有相關列的多列索引更適合，

前面我們提到過索引如何組織資料存盤的，從圖中可以看到多列索引時，索引的順序對于查詢是至關重要的，很明顯應該把選擇性更高的欄位放到索引的前面，這樣通過第一個欄位就可以過濾掉大多數不符合條件的資料，

索引選擇性是指不重復的索引值和資料表的總記錄數的比值，選擇性越高查詢效率越高，因為選擇性越高的索引可以讓MySQL在查詢時過濾掉更多的行，唯一索引的選擇性是1，這時最好的索引選擇性，性能也是最好的，

理解索引選擇性的概念后，就不難確定哪個欄位的選擇性較高了，查一下就知道了，比如：

SELECT * FROM payment where staff_id = 2 and customer_id = 584

是應該創建(staff_id,customer_id)的索引還是應該顛倒一下順序？執行下面的查詢，哪個欄位的選擇性更接近1就把哪個欄位索引前面就好，

select count(distinct staff_id)/count(*) as staff_id_selectivity,

       count(distinct customer_id)/count(*) as customer_id_selectivity,

       count(*) from payment

多數情況下使用這個原則沒有任何問題，但仍然注意你的資料中是否存在一些特殊情況，舉個簡單的例子，比如要查詢某個用戶組下有過交易的用戶資訊：

select user_id from trade where user_group_id = 1 and trade_amount > 0

MySQL為這個查詢選擇了索引(user_group_id,trade_amount)，如果不考慮特殊情況，這看起來沒有任何問題，但實際情況是這張表的大多數資料都是從老系統中遷移過來的，由于新老系統的資料不兼容，所以就給老系統遷移過來的資料賦予了一個默認的用戶組，這種情況下，通過索引掃描的行數跟全表掃描基本沒什么區別，索引也就起不到任何作用，

推廣開來說，經驗法則和推論在多數情況下是有用的，可以指導我們開發和設計，但實際情況往往會更復雜，實際業務場景下的某些特殊情況可能會摧毀你的整個設計，

4、避免多個范圍條件

實際開發中，我們會經常使用多個范圍條件，比如想查詢某個時間段內登錄過的用戶：

select user.* from user where login_time > '2017-04-01' and age between 18 and 30;

這個查詢有一個問題：它有兩個范圍條件，login_time列和age列，MySQL可以使用login_time列的索引或者age列的索引，但無法同時使用它們，

5、覆寫索引

如果一個索引包含或者說覆寫所有需要查詢的欄位的值，那么就沒有必要再回表查詢，這就稱為覆寫索引，覆寫索引是非常有用的工具，可以極大的提高性能，因為查詢只需要掃描索引會帶來許多好處：

• 索引條目遠小于資料行大小，如果只讀取索引，極大減少資料訪問量

• 索引是有按照列值順序存盤的，對于I/O密集型的范圍查詢要比隨機從磁盤讀取每一行資料的IO要少的多

6、使用索引掃描來排序

MySQL有兩種方式可以生產有序的結果集，其一是對結果集進行排序的操作，其二是按照索引順序掃描得出的結果自然是有序的，如果explain的結果中type列的值為index表示使用了索引掃描來做排序，

掃描索引本身很快，因為只需要從一條索引記錄移動到相鄰的下一條記錄，但如果索引本身不能覆寫所有需要查詢的列，那么就不得不每掃描一條索引記錄就回表查詢一次對應的行，這個讀取操作基本上是隨機I/O，因此按照索引順序讀取資料的速度通常要比順序地全表掃描要慢，

在設計索引時，如果一個索引既能夠滿足排序，又滿足查詢，是最好的，

只有當索引的列順序和ORDER BY子句的順序完全一致，并且所有列的排序方向也一樣時，才能夠使用索引來對結果做排序，如果查詢需要關聯多張表，則只有ORDER BY子句參考的欄位全部為第一張表時，才能使用索引做排序，ORDER BY子句和查詢的限制是一樣的，都要滿足最左前綴的要求（有一種情況例外，就是最左的列被指定為常數，下面是一個簡單的示例），其它情況下都需要執行排序操作，而無法利用索引排序，

// 最左列為常數，索引：(date,staff_id,customer_id)

select  staff_id,customer_id from demo where date = '2015-06-01' order by staff_id,customer_id

7、冗余和重復索引

冗余索引是指在相同的列上按照相同的順序創建的相同型別的索引，應當盡量避免這種索引，發現后立即洗掉，比如有一個索引(A,B)，再創建索引(A)就是冗余索引，冗余索引經常發生在為表添加新索引時，比如有人新建了索引(A,B)，但這個索引不是擴展已有的索引(A)，

大多數情況下都應該盡量擴展已有的索引而不是創建新索引，但有極少情況下出現性能方面的考慮需要冗余索引，比如擴展已有索引而導致其變得過大，從而影響到其他使用該索引的查詢，

8、洗掉長期未使用的索引

定期洗掉一些長時間未使用過的索引是一個非常好的習慣，

關于索引這個話題打算就此打住，最后要說一句，索引并不總是最好的工具，只有當索引幫助提高查詢速度帶來的好處大于其帶來的額外作業時，索引才是有效的，對于非常小的表，簡單的全表掃描更高效，對于中到大型的表，索引就非常有效，對于超大型的表，建立和維護索引的代價隨之增長，這時候其他技術也許更有效，比如磁區表，最后的最后，explain后再提測是一種美德，

優化COUNT()查詢

COUNT()可能是被大家誤解最多的函式了，它有兩種不同的作用，其一是統計某個列值的數量，其二是統計行數，統計列值時，要求列值是非空的，它不會統計NULL，如果確認括號中的運算式不可能為空時，實際上就是在統計行數，最簡單的就是當使用COUNT(*)時，并不是我們所想象的那樣擴展成所有的列，實際上，它會忽略所有的列而直接統計所有的行數，

我們最常見的誤解也就在這兒，在括號內指定了一列卻希望統計結果是行數，而且還常常誤以為前者的性能會更好，但實際并非這樣，如果要統計行數，直接使用COUNT(*)，意義清晰，且性能更好，

有時候某些業務場景并不需要完全精確的COUNT值，可以用近似值來代替，EXPLAIN出來的行數就是一個不錯的近似值，而且執行EXPLAIN并不需要真正地去執行查詢，所以成本非常低，通常來說，執行COUNT()都需要掃描大量的行才能獲取到精確的資料，因此很難優化，MySQL層面還能做得也就只有覆寫索引了，如果不還能解決問題，只有從架構層面解決了，比如添加匯總表，或者使用redis這樣的外部快取系統，

優化關聯查詢

在大資料場景下，表與表之間通過一個冗余欄位來關聯，要比直接使用JOIN有更好的性能，如果確實需要使用關聯查詢的情況下，需要特別注意的是：

1. 確保ON和USING字句中的列上有索引，在創建索引的時候就要考慮到關聯的順序，當表A和表B用列c關聯的時候，如果優化器關聯的順序是A、B，那么就不需要在A表的對應列上創建索引，沒有用到的索引會帶來額外的負擔，一般來說，除非有其他理由，只需要在關聯順序中的第二張表的相應列上創建索引（具體原因下文分析），

2. 確保任何的GROUP BY和ORDER BY中的運算式只涉及到一個表中的列，這樣MySQL才有可能使用索引來優化，

要理解優化關聯查詢的第一個技巧，就需要理解MySQL是如何執行關聯查詢的，當前MySQL關聯執行的策略非常簡單，它對任何的關聯都執行嵌套回圈關聯操作，即先在一個表中回圈取出單條資料，然后在嵌套回圈到下一個表中尋找匹配的行，依次下去，直到找到所有表中匹配的行為為止，然后根據各個表匹配的行，回傳查詢中需要的各個列，

太抽象了？以上面的示例來說明，比如有這樣的一個查詢：

SELECT A.xx,B.yy

FROM A INNER JOIN B USING(c)

WHERE A.xx IN (5,6)

假設MySQL按照查詢中的關聯順序A、B來進行關聯操作，那么可以用下面的偽代碼表示MySQL如何完成這個查詢：

outer_iterator = SELECT A.xx,A.c FROM A WHERE A.xx IN (5,6);

outer_row = outer_iterator.next;

while(outer_row) {

    inner_iterator = SELECT B.yy FROM B WHERE B.c = outer_row.c;

    inner_row = inner_iterator.next;

    while(inner_row) {

        output[inner_row.yy,outer_row.xx];

        inner_row = inner_iterator.next;

    }

    outer_row = outer_iterator.next;

}

可以看到，最外層的查詢是根據A.xx列來查詢的，A.c上如果有索引的話，整個關聯查詢也不會使用，再看內層的查詢，很明顯B.c上如果有索引的話，能夠加速查詢，因此只需要在關聯順序中的第二張表的相應列上創建索引即可，

優化LIMIT分頁

當需要分頁操作時，通常會使用LIMIT加上偏移量的辦法實作，同時加上合適的ORDER BY字句，如果有對應的索引，通常效率會不錯，否則，MySQL需要做大量的檔案排序操作，

一個常見的問題是當偏移量非常大的時候，比如：LIMIT 10000 20這樣的查詢，MySQL需要查詢10020條記錄然后只回傳20條記錄，前面的10000條都將被拋棄，這樣的代價非常高，

優化這種查詢一個最簡單的辦法就是盡可能的使用覆寫索引掃描，而不是查詢所有的列，然后根據需要做一次關聯查詢再回傳所有的列，對于偏移量很大時，這樣做的效率會提升非常大，考慮下面的查詢：

SELECT film_id,description FROM film ORDER BY title LIMIT 50,5;

如果這張表非常大，那么這個查詢最好改成下面的樣子：

SELECT film.film_id,film.description

FROM film INNER JOIN (

    SELECT film_id FROM film ORDER BY title LIMIT 50,5

) AS tmp USING(film_id);

這里的延遲關聯將大大提升查詢效率，讓MySQL掃描盡可能少的頁面，獲取需要訪問的記錄后在根據關聯列回原表查詢所需要的列，

有時候如果可以使用書簽記錄上次取資料的位置，那么下次就可以直接從該書簽記錄的位置開始掃描，這樣就可以避免使用OFFSET，比如下面的查詢：

SELECT id FROM t LIMIT 10000, 10;

改為：

SELECT id FROM t WHERE id > 10000 LIMIT 10;

其它優化的辦法還包括使用預先計算的匯總表，或者關聯到一個冗余表，冗余表中只包含主鍵列和需要做排序的列，

優化UNION

MySQL處理UNION的策略是先創建臨時表，然后再把各個查詢結果插入到臨時表中，最后再來做查詢，因此很多優化策略在UNION查詢中都沒有辦法很好的時候，經常需要手動將WHERE、LIMIT、ORDER BY等字句“下推”到各個子查詢中，以便優化器可以充分利用這些條件先優化，

除非確實需要服務器去重，否則就一定要使用UNION ALL，如果沒有ALL關鍵字，MySQL會給臨時表加上DISTINCT選項，這會導致整個臨時表的資料做唯一性檢查，這樣做的代價非常高，當然即使使用ALL關鍵字，MySQL總是將結果放入臨時表，然后再讀出，再回傳給客戶端，雖然很多時候沒有這個必要，比如有時候可以直接把每個子查詢的結果回傳給客戶端，

結語

理解查詢是如何執行以及時間都消耗在哪些地方，再加上一些優化程序的知識，可以幫助大家更好的理解MySQL，理解常見優化技巧背后的原理，希望本文中的原理、示例能夠幫助大家更好的將理論和實踐聯系起來，更多的將理論知識運用到實踐中，

標籤：其他

上一篇：達夢產品技術支持-DM8-資料庫安裝

下一篇：MySQL使用mysqldump進行資料備份