前言
准備整理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，后續一直整理更新。
下一節，日志介紹。