1.1 MySQL邏輯架構
- 最上層的服務并不是MySQL所獨有的，大多數(shù)基于網(wǎng)絡的客戶端/服務器的工具或者服務都有類似的架構耳幢，比如連接處理、授權處理、安全等等
- 第二次架構是MySQL的核心服務功能所在氧吐，包括查詢解析讹蘑、分析、優(yōu)化筑舅、緩存以及所有的內(nèi)置函數(shù)（例如：日期座慰、時間、數(shù)學加密函數(shù)）翠拣，所有跨存儲引擎的功能都在這一層實現(xiàn)：存儲過程版仔、觸發(fā)器、視圖
- 第三層包含了存儲引擎误墓。存儲引擎負責MySQL數(shù)據(jù)的存儲和提取蛮粮，服務器通過API于存儲引擎進行通信。這些接口屏蔽了不同存儲引擎之間的差異谜慌。存儲引擎API包含幾十個底層函數(shù)然想，用于執(zhí)行諸如”開始一個事務“或者”根據(jù)主鍵提取一行記錄“等操作。但存儲器不會去解析SQL欣范，不同存儲引擎之間也不會通信变泄，只是簡單的響應上層服務器的請求。
1.1.1 連接管理與安全性
每個客戶端鏈接都會在服務器進程中擁有一個線程熙卡，這個連接的查詢只會在這個線程中執(zhí)行杖刷，該線程只能輪流在某個CUP核心或者CPU中允許。服務器會負責緩存線程驳癌，因為不需要為每個新建的鏈接創(chuàng)建或者銷毀線程滑燃。
當客戶端連接到MySQL服務器時，服務器需要進行認證颓鲜，認證基于用戶名表窘、原始主機信息和密碼。一旦客戶端連接成功甜滨，服務器會繼續(xù)驗證客戶端是否具有執(zhí)行某個特定操作的權限乐严。
1.1.2 優(yōu)化與執(zhí)行
MySQL會解析查詢，并創(chuàng)建內(nèi)部數(shù)據(jù)結構（解析樹）衣摩，然后對其進行各種優(yōu)化昂验，包括重寫查詢、決定表的讀取順序艾扮，以及選擇合適的索引等既琴。用戶可以通過特殊的關鍵字提示（hint）優(yōu)化器，影響它的決策過程泡嘴。也可以請求優(yōu)化器解釋（explain）優(yōu)化過程的各個因素甫恩，使用戶可以知道服務器是如何進行優(yōu)化決策的，并提供一個參考基準酌予，便于用戶重構查詢和schema（計劃）磺箕，修改相關配置奖慌，使盡可能高效運行。
對于select查詢松靡，在解析查詢之前简僧，服務器會先檢查查詢緩存（query cache），如果能夠在其中找到對應的查詢击困，服務器就不必再執(zhí)行查詢解析涎劈、優(yōu)化和執(zhí)行的整個過程，而是直接返回查詢緩存中的結果集合阅茶。
1.2.并發(fā)控制
服務器層與層出引擎層的并發(fā)控制
1.2.1 讀寫鎖
共享鎖和排他鎖也叫讀鎖和寫鎖
讀鎖是共享的蛛枚，或者說叫互不阻塞的，寫鎖是排他的脸哀，寫鎖會其他的讀鎖和寫鎖蹦浦。
1.2.2 鎖粒度
表鎖
最基本的鎖策略，并且是開銷最小的策略
行級鎖
行級鎖可以最大程序的支持并發(fā)處理撞蜂，同時也帶來了最大的鎖開銷盲镶。行級鎖只會在存儲引擎層實現(xiàn)，而在MySQL服務層沒有實現(xiàn)蝌诡。
1.3 事務
ACID
- 原子性（atomicity）一個事務必須被視為一個不可分割的最小工作單元
- 一致性（consistency）從一個一致性的狀態(tài)到另外一個一致性的狀態(tài)
- 隔離性（isolation）事務所做的修改溉贿，在其他的事務是不可見的
- 持久性（durability）一旦事務提交，則其所作的修改會永久保存到數(shù)據(jù)庫中
1.3.1 隔離級別
-
未提交讀（READ UNCOMMITTED）
事務中的修改浦旱，即使沒提交宇色，在其他事務中都是可見的，事務可以讀取未提交的數(shù)據(jù)颁湖，也被成為臟讀宣蠕。 -
提交讀（READ COMMITTED）
沒提交前，在其他事務中都是不可見的甥捺，也叫不可重復讀 -
可重復讀（REPETABLE READ）
保證在同一個十五中多次讀取同樣的記錄的結果是一致的抢蚀，但是可能會導致出現(xiàn)幻讀（MySQL的默認事務隔離級別，InnerDB通過多版本并發(fā)控制MVCC解決了幻讀問題） -
可串行化（SERIALIZEBLE）
最高的隔離級別镰禾，強制事務串行執(zhí)行皿曲，簡單來說就是會在讀取的每一行數(shù)據(jù)上加鎖，所以可能會導致大量的超時和鎖爭斗的問題吴侦。
| 隔離級別 | 臟讀可能性 | 不可重復性讀可能性 | 幻讀可能性 | 加鎖讀 |
|---|---|---|---|---|
| READ UNCOMMITTED | Yes | Yes | Yes | No |
| READ COMMITTED | No | Yes | Yes | No |
| REPETABLE READ | No | No | Yes | No |
| SERIALIZEBLE | No | No | No | Yes |
1.3.2 死鎖
兩個或者多個事務在同一個資源上相互占用谷饿，并請求鎖定對方占用的資源，從而導致惡心循環(huán)的現(xiàn)象妈倔。
InnerDB目前處理死鎖的方法是將最少行級排他鎖的事務進行回滾
1.3.3 事務日志
事務日志可以幫助提高事務的效率，使用事務日志绸贡，存儲引擎在修改表的數(shù)據(jù)是只需要修改其內(nèi)存拷貝盯蝴，再把該修改行為記錄到持久在硬盤上的事務日志中毅哗，而不是每次都將修改的數(shù)本身持久到磁盤。
1.3.4 MySQL中的事務
自動提交（AUTOCOMMIT）
MySQL默認采用自動提交模式捧挺，如果不是顯示開始一個事務虑绵，則每個查詢都被當做一個事務執(zhí)行提交操作∶隼樱可以通過設置AUTOCOMMIT變量來啟用或者禁用自動提交模式翅睛。
