mysql 的邏輯架構分為三層： 最上層的服務大多數基於網路的客戶端、伺服器的工具或者服務都有類似的架構，比如連接處理，授權認證、安全等 第二層架構：mysql的核心服務功能都在這一層，包括查詢解析，分析，優化，緩存以及所有的內置函數，所有跨存儲引擎的功能都在這一層實現：存儲過程，觸發器、視圖 第三 ...
mysql 的邏輯架構分為三層：
最上層的服務大多數基於網路的客戶端、伺服器的工具或者服務都有類似的架構，比如連接處理，授權認證、安全等
第二層架構：mysql的核心服務功能都在這一層，包括查詢解析，分析，優化，緩存以及所有的內置函數，所有跨存儲引擎的功能都在這一層實現：存儲過程，觸發器、視圖
第三層：包含存儲引擎。負責數據的存儲和提取，innoDB是個例外，它會解析外鍵定義，因為mysql伺服器本身沒有實現該功能
連接管理與安全性：
當客戶端連接到mysql伺服器是，伺服器需要對其進行認證，認證基於用戶名，原始主機信息和密碼，一旦客戶端連接成功，伺服器 會繼續驗證該客戶端是否具有執行某個特定查詢的許可權
優化與執行：
mysql會解析查詢，並創建內部數據結構（解析樹），然後對其進行各種優化，包括重寫查詢，決定表的讀取順序，以及選擇合適的索引，用戶可以通過特殊的關鍵字提示優化器，影響他的決策過程，也可以請求優化器解釋優化過程的各個因素，使yoghurt可以知道伺服器是如何進行優化決策的，並提供一個參考基準，便於用戶重構查詢和修改相關配置，優化查詢效率
存儲引擎對於優化查詢時有影響的
對於select語句，在解析查詢之前，伺服器會先檢查緩存，如果能找到對應的查詢，伺服器就不會再執行查詢解析，優化和執行的整個過程，而是直接返回查詢結果
併發控制：
只要有多個查詢需要在同一時刻修改數據，都會產生併發控制的問題。
如果應用鎖可以保證數據的完整性，不被破壞，但是並不支持併發處理。
兩個層面的併發控制：伺服器層和存儲引擎層
讀寫鎖：通過實現一個由兩種類型的鎖組成的鎖系統來解決問題，也稱作共用鎖和排它鎖或者讀鎖和寫鎖
讀鎖是共用的，互相不阻塞的，而寫鎖則是排他的，
鎖粒度：一種提高共用資源併發性的方式就是讓鎖定對象更有選擇性，儘量只鎖定需要修改的部分數據，而不是所有資源。更理想的方式是，是對會修改的數據片進行精確的鎖定，
在任何時候，在給定的資源上，鎖定的數據量越少，則系統的併發程度越高，只要相互之間不發生衝突即可
所謂的鎖策略，就是在鎖的開銷和數據的安全性之間尋求平衡，大多數商業資料庫系統沒有提供能多的選擇，一般都是在表上施加行級鎖，而mysql則提供了多種選擇，每種mysql存儲引擎都可以實現自己的鎖策略和鎖粒度
表鎖：
鎖開銷最小的策略，會鎖定整張表，寫鎖也比讀鎖優先順序更高，一個寫鎖請求可能會被插入到讀鎖隊列的前面
行級鎖：
最大程度地支持併發處理，同時也帶來最大的鎖開銷，行級鎖只在存儲引擎層實現，伺服器層沒有實現，所有的引擎都以自己的方式實現了鎖
事務：ACID
atomicity consistency isolation durability
每種存儲引擎實現的隔離級別不盡相同
四種隔離級別：innodb引擎支持所有隔離級別
read uncommitted：未提交讀，事務可以讀取未提交的數據，臟讀（很少使用）
read committed：提交讀，大多數資料庫系統的預設隔離級別都是read committed，但mysql不是，這和個級別有時候也叫做不可重覆讀，兩次執行同樣的查詢可能會得到不一樣的結果
repeatable read：可重覆讀，是mysql的預設事務隔離級別，該級別保證了在同一個事務中多次讀取同樣的記錄結果是一致的。但是無法解決另外一個幻讀問題。幻讀指的是當某個事務在讀取某個範圍內的記錄時，另外一個事務又在該範圍內插入了新的記錄，檔之前的事務再次讀取該範圍的記錄時，會產生幻行。
innodb和xtradb存儲引擎通過多版本併發控制解決了幻讀的問題。
serializable：可串列化，最高的隔離級別，強制事務串列執行，避免幻讀問題。也很少用。
事務日誌;
幫助提高事務的效率，使用事務日誌，存儲引擎在修改表的數據時只需要修改其記憶體拷貝，再把該修改行為記錄到持久在硬碟上的事務日誌中，而不用每次都將修改的數據本身持久到磁碟，事務日誌採用的追加的方式，因此寫日誌的操作時磁碟上一小塊區域內的順序I/O操作，而不像隨機I/O需要在磁碟的多個地方移動磁頭，所以採用事務日誌的方式相對來說快的多
修改數據需要寫兩次磁碟
mysql中的事務
兩種事務型的存儲引擎：innodb和NDB Cluster
SET AUTOCOMMIT = 0 ;設置禁用自動提交模式，修改AUTOCOMMIT對本身就是非事務型的表，不會有任何影響。
有些命令在執行之前會強制執行commit提交當前的活動事務。
SET TRANSACTION ISOLATION LEVEL read committed；設置隔離級別。可以在配置文件中設置整個資料庫的隔離級別，也可以只改變當前會話的隔離級別
在事務中混合使用存儲引擎
mysql伺服器層不管理事務，事務是由下層的存儲引擎實現的，所以在同一個事務中，使用多種存儲引擎是不可靠的
MVCC：多版本併發控制
innodb的mvcc:通過在每行記錄後面保存兩個隱藏的列來實現的，一個列保存了行的創建時間，一個保存行的過期時間（刪除時間），存儲的並不是實際的時間值，而是系統版本號。每開始一個新的事務，系統版本號都會自動遞增。
不同的存儲引擎保存數據和索引的方式是不同的，但表的定義則是在mysql服務層統一處理的
SHOW TABLE STATUS LIKE 'user';顯示相關表信息
innodb是mysql的預設事務型引擎，被設計用來處理大量的短期事務，短期事務大部分情況是正常提交的，很少會被回滾，
innodb
innodb基於聚簇索引建立，innodb的索引結構和mysql的其他存儲引擎有很大的不同，聚簇索引對主鍵查詢有很高的性能，不過它的二級索引中必須包含主鍵列，若表上的索引較多的話，主鍵應當儘可能小。存儲格式是平臺獨立的，可移植。崩潰後可安全恢復
myisam存儲引擎;崩潰後無法恢復。支持數據修複，支持全文索引，基於分詞創建的索引，對整張表加鎖，寫鎖具有排他性，讀鎖共用，不能很好的支持高併發
Memory引擎：基於記憶體，所以不保存數據 ，支持hash索引，是表級鎖，併發寫入性能較低， 應用場景：用於保存數據分析中產生 的中間數據，用於查找或者映射表，MySQL在執行查詢的過程中需要使用臨時表來保存中間結果，內部使用的臨時表就是memory表。
NDB cluster引擎：
mysql伺服器、NDB集群存儲引擎，以及分散式的，share-nothing的，容災的，高可用的NDB資料庫的組合，被稱為mysql集群。
第三方存儲引擎：
OLTP：XtraDB是基於innodb引擎的一個改進版本，可以作為innodb的一個完全的替代產品。
另外還有一些和innodb非常類似的OLTP類存儲引擎，比如都支持acid事務和mvcc,其中一個就是pbxt。對固態存儲ssd提供了適當的支持。
tokudb引擎使用了一種新的叫做分形樹的索引數據結構，該結構是緩存無關的，因此即使其大小超過記憶體性能也不會下降，是一種大數據存儲引擎，因為擁有很高的壓縮比，可以在很大的數據量上創建大量索引 。
面向列的存儲引擎：
mysql預設是面向行的，伺服器的查詢也是以行為單位處理的，
infobright是最有名的面向列的存儲引擎，在非常的數據量（數十TB）時，該引擎工作良好。視為數據分析和數據倉庫應用設計的。數據高度壓縮，按照塊進行排序，每個塊都對應一組元數據。訪問元數據即可決定是否跳過該塊，該引擎不支持縮影。
參考文獻《高性能mysql》
