數據庫存儲引擎是數據庫底層軟件組織，數據庫管理系統（DBMS）使用數據引擎進行創建、查詢、更新和刪除數據。不同的存儲引擎提供不同的存儲機制、索引技巧、鎖定水平等功能，使用不同的存儲引擎，還可以 獲得特定的功能。現在許多不同的數據庫管理系統都支持多種不同的數據引擎。
MySQL的核心就是存儲引擎。
此圖就是mysql的內部架構，可以清楚的看到Mysql是由SQL接口，解析器，優化器，緩存，存儲
部件介紹
1. connectors
與其他編程語言中的sql 語句進行交互，如php、java等。
2. Management Serveices & Utilities
系統管理和控制工具
3. Connection Pool (連接池)
管理緩衝用戶連接，線程處理等需要緩存的需求
4. SQL Interface (SQL接口)
接受用戶的SQL命令，並且返回用戶需要查詢的結果。比如select from就是調用SQL Interface
5. Parser （解析器）
SQL命令傳遞到解析器的時候會被解析器驗證和解析。
主要功能：
a . 將SQL語句分解成數據結構，並將這個結構傳遞到後續步驟，後面SQL語句的傳遞和處理就是基於這個結構的
b. 如果在分解構成中遇到錯誤，那麼就說明這個sql語句是不合理的，語句將不會繼續執行下去
6. Optimizer (查詢優化器)
SQL語句在查詢之前會使用查詢優化器對查詢進行優化(產生多種執行計劃,最終數據庫會選擇最優化的方案去執行,儘快返會結果) 他使用的是“選取-投影-聯接”策略進行查詢。
用一個例子就可以理解： select uid,name from user where gender = 1;
這個select 查詢先根據where 語句進行選取，而不是先將表全部查詢出來以後再進行gender過濾
這個select查詢先根據uid和name進行屬性投影，而不是將屬性全部取出以後再進行過濾
將這兩個查詢條件聯接起來生成最終查詢結果.
7. Cache和Buffer (查詢緩存)
如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取數據。
這個緩存機制是由一系列小緩存組成的。比如表緩存，記錄緩存，key緩存，權限緩存等
8.Engine (存儲引擎)
存儲引擎是MySql中具體的與文件打交道的子系統。也是Mysql最具有特色的一個地方。
Mysql的存儲引擎是插件式的。它根據MySql AB公司提供的文件訪問層的一個抽象接口來定製一種文件訪問機制（這種訪問機制就叫存儲引擎）
MySQL查詢過程
數據庫通常不會被直接使用，而是由其他編程語言通過SQL語句調用mysql，由mysql處理並返回執行結果。那麼Mysql接受到SQL語句後，又是如何處理的呢？
mysql查詢過程
首先程序的請求會通過mysql的connectors與其進行交互，請求到處後，會暫時存放在連接池（connection pool)中並由處理器（Management Serveices & Utilities）管理。當該請求從等待隊列進入到處理隊列，管理器會將該請求丟給SQL接口（SQL Interface）。SQL接口接收到請求後，它會將請求進行hash處理並與緩存中的結果進行對比，如果完全匹配則通過緩存直接返回處理結果；否則，需要完整的走一趟流程：
(1)由SQL接口丟給後面的解釋器（Parser），上面已經說到，解釋器會判斷SQL語句正確與否，若正確則將其轉化為數據結構。
(2)解釋器處理完，便來到後面的優化器（Optimizer），它會產生多種執行計劃,最終數據庫會選擇最優化的方案去執行,儘快返會結果。
(3)確定最優執行計劃後，SQL語句此時便可以交由存儲引擎（Engine）處理，存儲引擎將會到後端的存儲設備中取得相應的數據，並原路返回給程序。
查詢緩存
在解析一個查詢語句前，如果查詢緩存是打開的，那麼MySQL會檢查這個查詢語句是否命中查詢緩存中的數據。如果當前查詢恰好命中查詢緩存，在檢查一次用戶權限後直接返回緩存中的結果。這種情況下，查詢不會被解析，也不會生成執行計劃，更不會執行。
MySQL將緩存存放在一個引用表（不要理解成table，可以認為是類似於HashMap的數據結構），通過一個哈希值索引，這個哈希值通過查詢本身、當前要查詢的數據庫、客戶端協議版本號等一些可能影響結果的信息計算得來。所以兩個查詢在任何字符上的不同（例如：空格、註釋），都會導致緩存不會命中。
如果查詢中包含任何用戶自定義函數、存儲函數、用戶變量、臨時表、MySQL庫中的系統表，其查詢結果都不會被緩存。比如函數NOW()或者CURRENT_DATE()會因為不同的查詢時間，返回不同的查詢結果，再比如包含CURRENT_USER或者CONNECION_ID()的查詢語句會因為不同的用戶而返回不同的結果，將這樣的查詢結果緩存起來沒有任何的意義。
既然是緩存，就會失效，那查詢緩存何時失效呢？MySQL的查詢緩存系統會跟蹤查詢中涉及的每個表，如果這些表（數據或結構）發生變化，那麼和這張表相關的所有緩存數據都將失效。正因為如此，在任何的寫操作時，MySQL必須將對應表的所有緩存都設置為失效。如果查詢緩存非常大或者碎片很多，這個操作就可能帶來很大的系統消耗，甚至導致系統僵死一會兒。而且查詢緩存對系統的額外消耗也不僅僅在寫操作，讀操作也不例外：
- 任何的查詢語句在開始之前都必須經過檢查，即使這條SQL語句永遠不會命中緩存
- 如果查詢結果可以被緩存，那麼執行完成後，會將結果存入緩存，也會帶來額外的系統消耗
基於此，我們要知道並不是什麼情況下查詢緩存都會提高系統性能，緩存和失效都會帶來額外消耗，只有當緩存帶來的資源節約大於其本身消耗的資源時，才會給系統帶來性能提升。但要如何評估打開緩存是否能夠帶來性能提升是一件非常困難的事情，也不在本文討論的範疇內。如果系統確實存在一些性能問題，可以嘗試打開查詢緩存，並在數據庫設計上做一些優化，比如：
- 用多個小表代替一個大表，注意不要過度設計
- 批量插入代替循環單條插入
- 合理控制緩存空間大小，一般來說其大小設置為幾十兆比較合適
- 可以通過SQL_CACHE和SQL_NO_CACHE來控制某個查詢語句是否需要進行緩存
最後的忠告是不要輕易打開查詢緩存，特別是寫密集型應用。如果你實在是忍不住，可以將query_cache_type設置為DEMAND，這時只有加入SQL_CACHE的查詢才會走緩存，其他查詢則不會，這樣可以非常自由地控制哪些查詢需要被緩存。
當然查詢緩存系統本身是非常複雜的，這裡討論的也只是很小的一部分，其他更深入的話題，比如：緩存是如何使用內存的？如何控制內存的碎片化？事務對查詢緩存有何影響等等，讀者可以自行閱讀相關資料，這裡權當拋磚引玉吧。
語法解析和預處理
MySQL通過關鍵字將SQL語句進行解析，並生成一顆對應的解析樹。這個過程解析器主要通過語法規則來驗證和解析。比如SQL中是否使用了錯誤的關鍵字或者關鍵字的順序是否正確等等。預處理則會根據MySQL規則進一步檢查解析樹是否合法。比如檢查要查詢的數據表和數據列是否存在等。
查詢優化
經過前面的步驟生成的語法樹被認為是合法的了，並且由優化器將其轉化成查詢計劃。多數情況下，一條查詢可以有很多種執行方式，最後都返回相應的結果。優化器的作用就是找到這其中最好的執行計劃。
MySQL使用基於成本的優化器，它嘗試預測一個查詢使用某種執行計劃時的成本，並選擇其中成本最小的一個。在MySQL可以通過查詢當前會話的last_query_cost的值來得到其計算當前查詢的成本。
查詢執行引擎
在完成解析和優化階段以後，MySQL會生成對應的執行計劃，查詢執行引擎根據執行計劃給出的指令逐步執行得出結果。整個執行過程的大部分操作均是通過調用存儲引擎實現的接口來完成，這些接口被稱為handler API。查詢過程中的每一張表由一個handler實例表示。實際上，MySQL在查詢優化階段就為每一張表創建了一個handler實例，優化器可以根據這些實例的接口來獲取表的相關信息，包括表的所有列名、索引統計信息等。存儲引擎接口提供了非常豐富的功能，但其底層僅有幾十個接口，這些接口像搭積木一樣完成了一次查詢的大部分操作。
返回結果給客戶端
查詢執行的最後一個階段就是將結果返回給客戶端。即使查詢不到數據，MySQL仍然會返回這個查詢的相關信息，比如該查詢影響到的行數以及執行時間等。
如果查詢緩存被打開且這個查詢可以被緩存，MySQL也會將結果存放到緩存中。
結果集返回客戶端是一個增量且逐步返回的過程。有可能MySQL在生成第一條結果時，就開始向客戶端逐步返回結果集了。這樣服務端就無須存儲太多結果而消耗過多內存，也可以讓客戶端第一時間獲得返回結果。需要注意的是，結果集中的每一行都會以一個滿足①中所描述的通信協議的數據包發送，再通過TCP協議進行傳輸，在傳輸過程中，可能對MySQL的數據包進行緩存然後批量發送。
總結MySQL整個查詢執行過程，總的來說分為6個步驟：
- 客戶端向MySQL服務器發送一條查詢請求
- 服務器首先檢查查詢緩存，如果命中緩存，則立刻返回存儲在緩存中的結果。否則進入下一階段
- 服務器進行SQL解析、預處理、再由優化器生成對應的執行計劃
- MySQL根據執行計劃，調用存儲引擎的API來執行查詢
- 將結果返回給客戶端，同時緩存查詢結果
性能優化建議
1、數據庫設計與數據類型優化
選擇數據類型只要遵循小而簡單的原則就好，越小的數據類型通常會更快，佔用更少的磁盤、內存，處理時需要的CPU週期也更少。越簡單的數據類型在計算時需要更少的CPU週期，比如，整型就比字符操作代價低，因而會使用整型來存儲ip地址，使用DATETIME來存儲時間，而不是使用字符串。
2、創建高性能索引
既然創建了索引，就要考慮索引能否用得上，否則一味的創建索引也會影響數據庫效率，隨著數據增加，索引也會增加，佔用磁盤空間，當對錶進行INSERT、UPDATE、DELETE的時候，索引也需要動態的維護，直接降低數據維護速度。
使用索引需要注意：
- 經常查詢的列上建索引；
- 在表與表的連接條件上建索引會可以加快連接查詢的速度；
- 在經常需要order by、group by、distinct的列上加索引，單獨的order by不會使用索引，索引考慮加where或者limit；
- 索引列不能夠有運算，也不能是函數的參數；
- 使用or的時候，存在沒有索引的列會使索引失效；
- 對於多列索引，必須遵循最左原則，否則索引失效；
- 多個範圍條件的時候，只能使用其中一個索引，無法同時都使用；
- 使用like的時候，%在前會導致索引失效；
- 如果列類型是字符串，該列不使用引號，會使索引失效；
- 如果mysql全表掃描比使用索引更快，索引失效；
3、特定類型查詢優化
優化COUNT()查詢
COUNT()可能是被大家誤解最多的函數了，它有兩種不同的作用，其一是統計某個列值的數量，其二是統計行數。統計列值時，要求列值是非空的，它不會統計NULL。如果確認括號中的表達式不可能為空時，實際上就是在統計行數。最簡單的就是當使用COUNT(*)時，並不是我們所想象的那樣擴展成所有的列，實際上，它會忽略所有的列而直接統計所有的行數。
我們最常見的誤解也就在這兒，在括號內指定了一列卻希望統計結果是行數，而且還常常誤以為前者的性能會更好。但實際並非這樣，如果要統計行數，直接使用COUNT(*)，意義清晰，且性能更好。
有時候某些業務場景並不需要完全精確的COUNT值，可以用近似值來代替，EXPLAIN出來的行數就是一個不錯的近似值，而且執行EXPLAIN並不需要真正地去執行查詢，所以成本非常低。通常來說，執行COUNT()都需要掃描大量的行才能獲取到精確的數據，因此很難優化，MySQL層面還能做得也就只有覆蓋索引了。如果不還能解決問題，只有從架構層面解決了，比如添加彙總表，或者使用redis這樣的外部緩存系統。
優化關聯查詢
在大數據場景下，表與表之間通過一個冗餘字段來關聯，要比直接使用JOIN有更好的性能。如果確實需要使用關聯查詢的情況下，需要特別注意的是：
- 確保ON和USING字句中的列上有索引。在創建索引的時候就要考慮到關聯的順序。當表A和表B用列c關聯的時候，如果優化器關聯的順序是A、B，那麼就不需要在A表的對應列上創建索引。沒有用到的索引會帶來額外的負擔，一般來說，除非有其他理由，只需要在關聯順序中的第二張表的相應列上創建索引（具體原因下文分析）。
- 確保任何的GROUP BY和ORDER BY中的表達式只涉及到一個表中的列，這樣MySQL才有可能使用索引來優化。
要理解優化關聯查詢的第一個技巧，就需要理解MySQL是如何執行關聯查詢的。當前MySQL關聯執行的策略非常簡單，它對任何的關聯都執行嵌套循環關聯操作，即先在一個表中循環取出單條數據，然後在嵌套循環到下一個表中尋找匹配的行，依次下去，直到找到所有表中匹配的行為為止。然後根據各個表匹配的行，返回查詢中需要的各個列。
優化UNION
MySQL處理UNION的策略是先創建臨時表，然後再把各個查詢結果插入到臨時表中，最後再來做查詢。因此很多優化策略在UNION查詢中都沒有辦法很好的時候。經常需要手動將WHERE、LIMIT、ORDER BY等字句“下推”到各個子查詢中，以便優化器可以充分利用這些條件先優化。
除非確實需要服務器去重，否則就一定要使用UNION ALL，如果沒有ALL關鍵字，MySQL會給臨時表加上DISTINCT選項，這會導致整個臨時表的數據做唯一性檢查，這樣做的代價非常高。當然即使使用ALL關鍵字，MySQL總是將結果放入臨時表，然後再讀出，再返回給客戶端。雖然很多時候沒有這個必要，比如有時候可以直接把每個子查詢的結果返回給客戶端。
閱讀更多 劉弋 的文章
