高效能mysql 第1章 mysql架構與曆史（1）

標籤：insert   過程   執行   寫日誌   資料檔案   oracle   服務層   comm   tab   

 

mysql邏輯架構圖：

 

第一層 用戶端

第二層（服務層）：針對所有類型的儲存引擎可以公用提取的部分。將儲存引擎抽離之後的其他部分都在這裡。如：查詢解析，分析最佳化，內建函數，預存程序，觸發器，視圖。

第三層（儲存引擎層）：儲存引擎負責mysql資料的儲存和提取。伺服器通過API與儲存引擎進行通訊。這些API屏蔽了不同儲存引擎的具體實現差異。儲存引擎API包含"開始一個事務"，"根據主鍵擷取一行資料"等操作。儲存引擎本身不會去解析sql。

註：mongdb也有儲存引擎。

 

資料庫通過讀鎖和寫鎖，又叫共用鎖定和排它鎖，來控制並發事務。

關於鎖粒度，mysql交給儲存引擎自己去管理，每種儲存引擎可以實現自己的鎖粒度和鎖策略。

不同的鎖策略，會帶來不同的效果，表鎖開銷最小，但是並發最差。行級鎖並發效能最好，但是開銷最大。

儘管鎖策略在儲存引擎上管理，但是在執行alter table這種操作的時候，服務層會直接使用表所，而忽視儲存引擎層的鎖機制。

 

隔離等級：

mysql支援四中隔離等級：

• read uncommitted：未提交讀
• read commited 提交讀（Oracle的預設隔離等級）
• repeatable read 可重複讀（mysql的預設隔離等級）
• serializable 序列化

 

註：可重複讀解決了不可重複讀取的問題（同一個資料在兩次讀取的時候結果不一樣）。序列化解決了幻讀的問題（兩次執行同一個where語句結果什麼結果條數不一致）。

疑惑：關於序列化，書上說mysql對每一行讀的資料都加鎖。如果這樣做的話，肯定能保證可重複讀，但是怎麼保證幻讀呢，因為對讀取的資料進行加鎖是不能阻塞insert操作的呢。

 

 

死結：關於死結的原因，一種是業務情境的操作導致，另外一些，是儲存引擎的實現方式導致的。

innodb能夠識別到死結現象，並復原持有最少排它鎖的事務。

 

交易記錄：

交易記錄可以提高事務的效率，mysql在update表的時候只需要修改記憶體中的資料，然後將修改行為記錄在硬碟的交易記錄中，這個事務的過程就算完了。不需要等待硬碟中的資料檔案被update才返回。交易記錄是硬碟上的一段順序儲存空間，可不是隨機的磁碟儲存，每次add都是採取追加的方式，交易記錄中的內容會持久化到硬碟資料檔案中。這種方式叫做預寫式日誌，需要寫兩次硬碟。

如果出現斷電，在重啟後，可以通過交易記錄恢複資料。

註：Mongodb最新的WiredTiger儲存引擎也有類似交易記錄的概念，不過不叫交易記錄，叫做預寫記錄檔（WAL: Write-Ahead Logging），因為mongdb沒有事務麼。

 

高效能mysql 第1章 mysql架構與曆史（1）