MySQL 基礎知識（基本架構、儲存引擎差異）

標籤：inno   線程   包含   日期   png   mysql   時間   set   意思   

前言：　　// MySQL 並發、非同步IO、進程劫持　　最近在看高效能 MySQL，記錄寫學習筆記：　　高效能 MySQL 學習筆記（一） 架構與曆史　　筆記核心內容：MySQL 伺服器基礎架構、各種儲存引擎之間的主要區別，以及這些區別的重要性； 一、MySQL 邏輯架構　　　　

 

　　第一層架構圖：　　　　也就是最上層的服務並不是 MySQL 專屬的，大多數基於網路的用戶端/伺服器的工具或者伺服器都有類似的架構，比如連結處理，授權認證，安全等等 ；　　　　// 每個用戶端串連都會在伺服器處理序中擁有一個線程這串連查詢只會在單獨的線程中執行，線程只能輪流在某個 CPU 核心或者 CPU 中運行。　　　　// 用戶端（應用）串連到 MySQL 時，MySQL 服務會對其串連做一些列的身份認證（例如使用者名稱密碼、許可權控制等）　　　　// 這也回答了許多開發人員在使用資料庫時，盲目的開關串連，甚至不關閉串連給 MySQL 伺服器帶來的損耗； 　　第二層架構：　　　　MySQL 核心服務和功能都在這一層，包括查詢解釋，分析，最佳化，緩衝以及所有的內建函數(例如，日期，時間，數學和加密函數)，　　　　所有跨儲存引擎的功能都在這一層實現：預存程序，觸發器，視圖等。　　　　// 查詢解釋：理解解析，將 SQL 的語句轉換成 MySQL 內部資料結構（解析樹）　　　　// 分析：對文法的分析，是否存在語法錯誤；　　　　// 最佳化：這是一個非常重的課題，還沒有深入到這裡來，大體瞭解意思為：將需要執行的 SQL 陳述式進行最佳化處理，如 where 條件後的順序等；　　　　// 內建函數：注意是內建，也可以自訂；但是不建議在 MySQL 上做這些操作，記住資料庫只是用來儲存資料的，資料庫的效能空間留給 CRUD　　　　// 後面章節對 MySQL 最佳化器單獨分析 　　第三層架構：　　　　包含了儲存引擎，儲存引擎負責MySql中資料的儲存和提取，和GNU/Linux寫的各個檔案系統一樣，每個儲存引擎都有它的優勢和劣勢，　　　　伺服器通過API與儲存引擎進行通訊，這些介面屏蔽了不同儲存引擎之間的差異，使得這些差異對於上層的查詢過程透明，　　　　儲存引擎 API 包含十幾個底層函數，用於執行諸如 ‘開始一個事務‘或者‘根據主鍵提取一行記錄‘等操作，　　　　但儲存引擎並不會去解析 SQL，不同儲存引擎之間也不會相互連信，而只是簡單的響應上層伺服器的請求。 二、MySQL 並發控制     　　並發：多條語句同時執行時，就會出現並發問題；　　控制並發且不出現資料錯誤等問題，就取決於資料庫系統如何在鎖上如何設計的了。　　MySQL 只一種可以支援到行級鎖的資料庫。MySQL 鎖分為：表鎖、行鎖；　　// update t_users set login_count = 0 where 1 = 1;          # 產生一個表級鎖　　// update t_users set age = 18 where id = 9527;              # 產生一個行級鎖 　　每種 MySQL 儲存引擎都可以實現自己的鎖策略和鎖粒度。　　// 鎖策略：所謂的鎖策略，就是在鎖的開銷和資料的安全性之間尋求平衡，這種平衡直接與效能掛鈎；　　// 鎖粒度：一種提高共用資源並發性的方式，讓鎖定的對象更有選擇性。 　　// 鎖定的資料量越小，則系統支撐的並發數量越高。 
三、死結     　　死結是指兩個或者多個事務（注意哈，一個單條的 update 語句其實本質上也是一個事務）在同一資源上互相佔用，　　並請求鎖定對方佔用的資源，從而導致的惡性死迴圈的現象。　　// 不過註解，理解為兩個人在互相等待；     　　MySQL 資料庫在死結現象上，實現了各種死結檢測和死結逾時的機制，　　比如 InnerDB 儲存引擎，它能檢測到死結的循環相依性，並立即返回一個錯誤。  四、儲存引擎　　　　　　儲存引擎重點學習兩個（InnerDB、MyISAM）：
　　// 其他儲存引擎用的很少，MySQL 官方也提供了一些 API，有很多愛好者在此基礎上自己實現了許多儲存引擎，          喜歡深挖的，可以去看看；        InnerDB：　　事務型儲存引擎，作為 MySQL 預設的儲存引擎，應該說是在 MySQL 4.0 + 以後的版本推出來的。　　他被設計用來處理大量的短期事務，短期事務大部分情況是正常提交的，很少會被復原。　　InnoDB的效能和自動崩潰恢複特性，使得他在非事務型儲存的需求中也很流行，　　除非有非常特別的原因需要使用其他的儲存引擎，否則應該有限考慮InnoDB引擎。 　　InnoDB 的資料存放區在資料表空間，資料表空間由InnoDB管理的一個黑盒子，由一系列的資料檔案組成。　　InnoDB 可以將每個表的資料和索引存放在單獨的檔案中。　　InnoDB 也可以使用裸裝置作為資料表空間的儲存介質，但現在的檔案系統是的裸裝置不再是必要的選擇。 　　InnoDB 採用 MVCC 支援高並發，並且實現了四個標準的隔離等級。　　其預設層級是 REPEATABLE READ，並且通過間隙鎖策略防止幻讀的出現，　　間隙鎖是的InnoDB不僅僅鎖定查詢涉及的行，還會對索引中的間隙進行鎖定，以防止幻行的插入。 　　InnoDB內部做了很多就花，包含從磁碟讀取資料時採用的可預測性預讀，　　能夠自動在記憶體中建立hash索引以加速讀操作的自適應雜湊索引，以及能夠加速插入操作的插入緩衝等。 　　作為事務型的儲存引擎，InnoDB通過一些機制和工具支援真正的熱備份，　　Oracle 提供的MySql Enterprise Backup , Percona提供的開源的XtraBackup都可以做到這一點。　　MySQL 的其他儲存引擎不支援熱備份，要擷取一致性視圖需要停止對所有表的寫入，而在讀寫混合情境中，停止寫入可能意味著停止讀取。 　　// 技術深度：http://blog.csdn.net/cd520yy/article/details/8541422           MyISAM：　　MyISAM 的鎖層級，不像 InnerDB 支援到行級鎖，它只支援到表級鎖，同時 MyISAM 不支援事務，　　沒有瞭解過的同學，不要在你執行了 Back 操作後一臉懵逼的問，明明復原了為什麼資料還是被提交了。 　　很早看過一篇關於 MySQL 儲存引擎的如何做選擇的文章，筆者對 InnerDB 和 MyISAM 分別做了讀寫的效能對比，　　毫無疑問，MyISAM 的讀寫操作是高於 InnerDB 的，但是 MyISAM 也有很多的弊端，所以在選擇時，應根據業務的需要作出決策，　　否則出了問題，也會是坑了隊友。如一些日誌表，就可以直接選擇 MyISAM。     　　MyISAM 不支援熱備份，但是可以手工或者自動執行檢查和修複操作，但這裡說的修複和事務恢複以及崩潰恢複是不同的概念。執　　行表的修複可能導致一些資料丟失，而且 修複操作是非常慢的。 五、如何選擇合適的儲存引擎 　　總結一句話：除非需要用到某些 InnerDB 不具備的特性，並且沒有其他辦法可以代替，否則應該優先選擇 InnerDB 儲存引擎；　　// 不是非常特殊的情況，不要混合使用多種儲存引擎； 　　不要輕易相信“MyISAM 比 InnerDB 快”之類的經驗之談，這個結論往往不是絕對的。　　在很多我們已知的情境中，InnerDB 的速度都可以讓 MyISAM 望塵莫及了，尤其是使用到聚簇索引，　　或者需要訪問的資料可以放入記憶體應用。

MySQL 基礎知識（基本架構、儲存引擎差異）