前言
準備整理mysql的基礎篇了，前面整理了sql語句序列的的《sql 語句系列（八百章）》，感覺很多用不上，就停下來了，後續還是會繼續整理。
mysql 基礎篇主要是對一些基礎進行整理，同時望請大佬能夠指點一二。之所以整理mysql，而不是sql server，一個是因為sql server 相對來說穩定，同時sql server 水很深，後續會整理一些被sql server 折磨的經歷。
這裡說一句公道話，sql server 從綜合來說的確比mysql 強，不然人家也不好意思收費。但是我們很多場景mysql 就足夠了，mysql 效率也不低，因為不用考慮到很多的場景，故而少量資料查詢可能比sql server 要好。
其實談那個效能怎麼樣，怎麼怎麼好，是沒有意義的，主要看怎麼用吧，一個設計不好的資料庫，引擎再怎麼好，也是泥坑。
好吧，下面就開始整理一下，比較基礎。
正文
網上有很多圖說明mysql的內部結構，我這裡重新化了一下:
好像市面上比較喜歡聊的InnoDB就屬於儲存引擎，儲存引擎 可以說是資料庫的核心。
如果把mysql 比作一臺電腦的話，那麼聯結器就是登陸介面。 查詢快取就是記憶體。 分析器和優化器就相當於編譯器。 執行器就相當於cpu。儲存引擎就相當於檔案系統。
還是那句話吧，任何一件東西都不是憑空產生，肯定有前面的借鑑之處，這裡面就借鑑了一些電腦整體架構的東西，又是一個套娃系統。
先來介紹一下聯結器。
聯結器，既然是連線的，那麼要保證兩個問題，一個是安全，一個是快速。
快速呢，這個可以通過高效的協議搞定。
安全呢，通過驗證機制搞定。
mysql 的這一套安全機制和連線協議其實是比較簡單的，這裡不細說，可以百度看看。
如果我們連線上了，那麼我們可以去進行檢視:
在寫完show processlist後面我又加了一個；,這條語句才執行了。
裡面查詢到兩個，第一個呢，是我使用工具進行連線，狀態是sleep。第二個是我們命令列介面進行了連線。
我這樣開啟一個庫:
那麼我們再show processlist 一下:
又進行了一個連線。
那麼這裡想說明的是，其實一個應用的連線數其實比我們想象的多。
如果我們的客戶端和伺服器的連線一直sleep 狀態，那麼8小時後又會斷開。
因為應用一般每秒處理很多請求，故而請求非常多，連線數自然非常多了，而mysql的連線數是有限的，因為人家要維持這麼多連線也不容易。
解決方案有兩個:
-
連線池。
-
長連線。
連線池 比較好理解哈，就是會維護一套自我自己，不會連線太多的數量，反覆利用。
長連線，就是像上面一樣進行連線，不斷開。
長連線有一個壞處，那就是應用程式和mysql 的連線，並不是http這種無狀態的，它可能你不斷的執行的時候給你記上一些小本本，這樣你的連線物件就越來越大了。
-
定期斷開長連線。使用一段時間，或者程式裡面判斷執行過一個佔用記憶體的大查詢後，斷開
連線，之後要查詢再重連。 -
如果你用的是MySQL 5.7或更新版本，可以在每次執行一個比較大的操作後，通過執行
mysql_reset_connection來重新初始化連線資源。這個過程不需要重連和重新做許可權驗證，
但是會將連線恢復到剛剛建立完時的狀態。
這裡面有個查詢快取，這個是來查詢如果這條語句前面查詢過，那麼就直接去快取裡面的值。
上圖中快取沒有很好的畫好，其實就是查詢的時候判斷是否有快取，直接是當前語句的hash值，查詢hash表看是否命中，如果這條語句的列的順序不同，都不會命中。
同樣，當啟動了快取，那麼當查詢完的時候會將該語句的hash值和查詢結果放入快取中。
網上很多人提及到不要開啟，因為如果查詢語句，只有表發生了改變，這個快取就失效了，而表很多時候都會進行更新。
也就是說要維護這套快取機制受益不如不用。
個人覺得還有一個重要的原因，那就是現在強大的快取架構，如redis 這樣的快取資料庫。讓應用去覺得哪個去快取是更好的，所以顯得雞肋了。
分析器：這個比較好理解了，比如我們寫一條select * from student,這個東西呢，mysql 根本執行不了，是為了讓我們的人類看的懂罷了。
這時候就解析成執行器能夠識別的語句。
優化器: 根據mysql能夠識別的語法，用一些演算法進行優化，比如說索引、表與表的連線。有些可能是負優化，因為演算法不可能照顧每一種場景。我們做的就是去迎合優化。
執行器: 這個時候判斷是否對這個表有相應的許可權，比如說查詢、更新許可權等，這裡就會進行許可權快取，所以這也是我們的連線物件會大的原因之一，這也是為啥我們斷開連線新的許可權才會生效的原因。
如果許可權通過，那麼就很好辦了，就進行執行，當然其中一些操作會呼叫到儲存引擎，這些後面介紹。
結
以上只是個人重新整理一下mysql，後續一直整理更新。
下一節，日誌介紹。