一條SQL語句的奇妙旅程

MySQL的邏輯架構

1.  鏈接器：負責用戶的身份認證和權限校驗。

2. 查詢緩存：這個在8.0之後的版本已經取締了，可是不影響設計思想的瞭解，即：當有一個SQL進來的時候，先會去匹配SQL語句，若是本地已經有緩存，即直接讀緩存，返回結果。乍一聽挺好的功能，爲何會被取締呢？這存在一些設計理念的問題，MySQL追求極高的性能，該功能在實際使用過程當中弊大於利，寫緩存/清緩存的過程可能會大幅度影響性能

3. 分析器/解析器：這個模塊主要是進行一些語法分析/詞法分析，你們可能以爲與本身關係不太大，其實咱們初學SQL語句的時候第一個打交道的就是這個模塊，好比當你輸入錯誤語句的時候，語法的錯誤在這層就已經發現了。

4. 預處理器：這個模塊會肯定你輸入的表和列是否真實存在，字段別名是否有歧義，主要是當你語法沒錯的時候，肯定是否符合這個場景。

5. 查詢優化器：這能夠說是server層最核心也是實戰最重要的地方了，首先，咱們每次能夠經過explain+sql來查看當前語句的各個屬性，這些屬性能給咱們調優很好的建議。這點會在下篇文章中細談，這篇文章整體是爲了打通全鏈路。
   其次，咱們能夠根據show warnings來查看查詢優化器到底作了哪些優化，從而考慮優化是否得當。

6. 執行引擎：這塊主要是對結果進行過濾和排序，這個模塊的命名有些歧義，其實真實的數據檢索並不是在這裏進行，這層進行的是對檢索的結果集進行一次過濾和排序。

7. 存儲引擎：這裏就是真正的核心了，也就是咱們一直所說的innodb、myisam等存儲引擎工做的地方，咱們全部的查詢檢索任務都是在這裏進行的，全部的存儲也是在這裏進行。這個模塊也會在以後的文章中分析。

如今來假設一條SQL來作全套了，那麼它會是怎樣的一個邏輯呢？

首先咱們客戶端與服務器之間會創建一個鏈接（這裏的鏈接是指那幾種進程通訊方式中的一種，大部分狀況下說的是TCP/IP進行鏈接的，過程當中須要咱們mysql -u root -p輸入密碼，就能夠進入mysql。

此時咱們能夠經過SQL語句進行增刪改查，當咱們輸入一條語句，假若在5.8版本以前，這條語句會進入查詢緩存，在這個模塊中先對SQL語句進行匹配，假若找到徹底匹配的緩存，則讀緩存返回結果，假若沒有匹配的，則會進入下一模塊。查詢到的結果會寫進寫緩存這也是之因此在5.8之後取締掉查詢緩存的緣由：寫緩存對性能是有必定的影響的，事實上這個影響甚至大於其對速度的提高。

進入下一模塊之後，會對語句進入一些詞法分析和語法分析，看看有沒有語法上的錯誤，初學者常常被卡在這個模塊，由於語句寫的不規範之類的問題。

再到後來，這條語句會進入預處理器，也就是看看你雖說的都對，語法都對，可是你搜索的列若是是我根本沒有的，那至關於什麼都沒有，若是一切正常，就再日後走。

此時進入了server層最核心的查詢優化器，這裏MySQL有本身的想法， 他會對你輸入的語句進行一些優化和重排，這裏有一個很細節可是很核心的點：任何關聯進入查詢優化器都會變成嵌套循環關聯，也就是說，不少複雜的關聯都會變成相似於左鏈接之類的關聯，其緣由也很是簡單，正如上述：執行引擎是對結果進行過濾和排序，那麼若是咱們能夠經過優化語句提早對語句進行過濾，這樣就能夠大幅度提升性能。當咱們查詢Explain+sql語句的時候會出現不少的屬性，咱們須要注意的是要避免外部排序的產生，由於這樣會產生巨大的性能影響。

查詢優化器畢竟不是十全十美的，它的不少優化多是好心沒作好事，最典型的就是臨時表了，首先臨時表這個東西自己是很是好的，它將中間過程的一些結果集存儲在內存上，頗有利於查詢過程的執行，可是有可能內存不足的狀況下，會將數據存儲在磁盤上，而磁盤參與讀寫必定會帶來非必要的資源和性能消耗，所以咱們必須結合實際狀況考究某些屬性的存在是否合理。

查詢優化器以後，查詢進入了執行引擎，在這裏其實並未進行太多的事情，執行引擎主要是調度存儲引擎，而後存儲引擎在硬盤中去檢索，而後拿到結果返回執行引擎，由執行引擎進行結果的過濾和排序，而後返回結果集回到客戶端，若是是在5.8之前的話，會放入寫緩存。

接下來就是核心的問題了：存儲引擎。

咱們經常使用的存儲引擎大概是innodb和myisam，這兩任默認引擎撐起了MySQL的半邊天，如今我會比較粗略的介紹一下兩個引擎，詳細的文章會在後期輸出。

innodb存儲引擎與myisam存儲引擎

首先咱們先認識所謂存儲引擎最重要的兩個功能就是存儲與查詢，那麼咱們從存儲和查詢兩個方面來分析一下這兩個引擎的特色。

存儲方面：
首先當咱們存儲數據的時候，由於這兩個引擎都是基於磁盤的，innodb是將索引和數據放在一塊兒的，這跟其索引結構有關，當進行存儲的時候，innodb將全部的數據都存儲在一塊兒；而myisam則是將索引數據和真實數據分開存儲，這樣實際上是經過索引進行檢索，獲得的結果是一個真實數據的指針，而後進入數據文件中進行隨機io。這就決定了一點，若是咱們是innodb存儲引擎的話，主鍵儘可能自增，由於若是非自增，會致使不能進行順序io，性能會有很大的退化。而myisam的數據存儲位置不能輕易移動，由於這樣會致使索引失效，也會影響性能。

查詢方面：
查詢就像翻詞典同樣，索引就像目錄和頁碼，這是很是重要的一部分，不少初學者以爲本身很是少用到索引，其實否則，咱們常常用到的主鍵即是最標準的索引，當你的查詢命中索引的時候，即可以進入高速列車，爲何呢？由於數據結構，在此強調一下，一直很認同程序=數據結構+算法，數據結構很是重要，若是咱們能命中索引，就能夠進入索引的數據結構，此時要麼是哈希索引，要麼是b+樹索引，這兩種索引一個的複雜度爲O(1)，一個是O(log(M)N），其中M爲索引關鍵字，N爲總關鍵字數量，很容易看到，這種速度比全表遍歷好了太多了，因此若是命中索引的話，就能夠大幅度提升速率。

固然這兩點雖然重要，可是都不是兩種引擎最大的區別，這兩種存儲引擎最大的差異在於事務性和鎖的粒度上，這也是innodb彎道超車最重要的緣由。

事務性

隨着數據庫的應用場景愈來愈多，咱們對數據的安全性有了愈來愈多的需求，myisam不支持事務，這致使這種存儲引擎很快的落時了。

鎖粒度

並非說myisam徹底不考慮數據安全性，只是它的粒度有些太大了，它爲了數據的安全直接動用了表級鎖，直接致使性能影響太大。