後端程序員必備：mysql數據庫相關流程圖/原理圖

前言

整理了一些Mysql數據庫相關流程圖/原理圖，作一下筆記，你們一塊兒學習。

1.mysql主從複製原理圖

mysql主從複製原理是大廠後端的高頻面試題，瞭解mysql主從複製原理很是有必要。

主從複製原理，簡言之，就三步曲，以下：

• 主數據庫有個bin-log二進制文件，紀錄了全部增刪改Sql語句。（binlog線程）
• 從數據庫把主數據庫的bin-log文件的sql語句複製過來。（io線程）
• 從數據庫的relay-log重作日誌文件中再執行一次這些sql語句。（Sql執行線程）

以下圖所示：

上圖主從複製分了五個步驟進行：

步驟一：主庫的更新事件(update、insert、delete)被寫到binlog

步驟二：從庫發起鏈接，鏈接到主庫。

步驟三：此時主庫建立一個binlog dump thread，把binlog的內容發送到從庫。

步驟四：從庫啓動以後，建立一個I/O線程，讀取主庫傳過來的binlog內容並寫入到relay log

步驟五：還會建立一個SQL線程，從relay log裏面讀取內容，從Exec_Master_Log_Pos位置開始執行讀取到的更新事件，將更新內容寫入到slave的db

2.Mysql邏輯架構圖

若是能在腦海中構建出MySql各組件之間如何協同工做的架構圖，就會有助於深刻理解MySql服務器

Mysql邏輯架構圖主要分三層：

1) 第一層負責鏈接處理，受權認證，安全等等

• 每一個客戶端鏈接都會在服務器進程中擁有一個線程，服務器維護了一個線程池，所以不須要爲每個新建的鏈接建立或者銷燬線程。
• 當客戶端鏈接到Mysql服務器時，服務器對其進行認證，經過用戶名和密碼認證，也能夠經過SSL證書進行認證。
• 一旦客戶端鏈接成功，服務器會繼續驗證客戶端是否具備執行某個特定查詢的權限。

2）第二層負責編譯並優化SQL

• 這一層包括查詢解析，分析，優化，緩存以及全部的的內置函數。
• 對於SELECT語句，在解析查詢前，服務器會先檢查查詢緩存，若是能在其中找到對應的查詢結果，則無需再進行查詢解析、優化等過程，直接返回查詢結果。
• 全部跨存儲引擎的功能都在這一層實現:存儲過程，觸發器，視圖。

3）第三層是存儲引擎。

• 存儲引擎負責在MySQL中存儲數據、提取數據。
• 存儲引擎經過API與上層進行通訊，這些API屏蔽了不一樣存儲引擎之間的差別，使得這些差別對上層查詢過程透明。
• 存儲引擎不會去解析SQL，不一樣存儲引擎之間也不會相互通訊，而只是簡單地響應上層服務器的請求。

3.InnoDb 邏輯存儲結構圖

從InnoDb 存儲引擎的邏輯存儲結構看，全部數據都被邏輯地存放在一個空間中，稱之爲表空間（tablespace）。表空間又由段（segment），區（extent），頁（page）組成。頁在一些文檔中有時候也稱爲塊（block）。 InnoDb 邏輯存儲結構圖以下：

表空間（tablespace）

• 表空間是Innodb存儲引擎邏輯的最高層，全部的數據都存放在表空間中。
• 默認狀況下，Innodb存儲引擎有一個共享表空間ibdata1,即全部數據都存放在這個表空間中內。
• 若是啓用了innodb_file_per_table參數，須要注意的是每張表的表空間內存放的只是數據、索引、和插入緩衝Bitmap，其餘類的數據，好比回滾(undo)信息、插入緩衝檢索頁、系統事物信息，二次寫緩衝等仍是放在原來的共享表內的。

段（segment）

• 表空間由段組成，常見的段有數據段、索引段、回滾段等。
• InnoDB存儲引擎表是索引組織的，所以數據即索引，索引即數據。數據段即爲B+樹的葉子結點，索引段即爲B+樹的非索引結點。
• 在InnoDB存儲引擎中對段的管理都是由引擎自身所完成，DBA不能也不必對其進行控制。

區（extent）

• 區是由連續頁組成的空間，在任何狀況下每一個區的大小都爲1MB。
• 爲了保證區中頁的連續性，InnoDB存儲引擎一次從磁盤申請4~5個區。
• 默認狀況下，InnoDB存儲引擎頁的大小爲16KB，一個區中一共64個連續的區。

頁（page）

• 頁是InnoDB磁盤管理的最小單位。
• 在InnoDB存儲引擎中，默認每一個頁的大小爲16KB。
• 從InnoDB1.2.x版本開始，能夠經過參數innodb_page_size將頁的大小設置爲4K，8K，16K。
• InnoDB存儲引擎中，常見的頁類型有：數據頁，undo頁，系統頁，事務數據頁，插入緩衝位圖頁，插入緩衝空閒列表頁等。

4.Innodb頁結構相關示意圖

Innodb頁結構單體圖

InnoDB數據頁由如下7部分組成，如圖所示：

其中File Header、Page Header、File Trailer的大小是固定的，分別爲38，56，8字節，這些空間用來標記該頁的一些信息，如Checksum，數據頁所在B+樹索引的層數等。User Records、Free Space、Page Directory這些部分爲實際的行記錄存儲空間，所以大小是動態的。

下邊咱們用表格的方式來大體描述一下這7個部分：

記錄在頁中的存儲流程圖

每當咱們插入一條記錄，都會從Free Space部分，也就是還沒有使用的存儲空間中申請一個記錄大小的空間劃分到User Records部分，當Free Space部分的空間所有被User Records部分替代掉以後，也就意味着這個頁使用完了，若是還有新的記錄插入的話，就須要去申請新的頁了，這個過程的圖示以下：

不一樣Innodb頁構成的數據結構圖

一張表中能夠有成千上萬條記錄，一個頁只有16KB，因此可能須要好多頁來存放數據。不一樣頁其實構成了一條雙向鏈表，File Header是InnoDB頁的第一部分，它的FIL_PAGE_PREV和FIL_PAGE_NEXT就分別表明本頁的上一個和下一個頁的頁號，即鏈表的上一個以及下一個節點指針。

5.Innodb索引結構圖

咱們先看一份數據表樣本，假設Col1是主鍵，以下：

B+樹彙集索引結構圖

• 彙集索引就是以主鍵建立的索引
• 彙集索引在葉子節點存儲的是表中的數據

非彙集索引結構圖

假設索引列爲Col3，索引結構圖以下：

• 非彙集索引就是以非主鍵建立的索引
• 非彙集索引在葉子節點存儲的是主鍵和索引列
• 使用非彙集索引查詢出數據時，拿到葉子上的主鍵再去查到想要查找的數據。(拿到主鍵再查找這個過程叫作回表)
• 假設所查詢的列，恰好都是索引對應的列，不用再回表查，那麼這個索引列，就叫覆蓋索引。

InnoDB 鎖類型思惟導圖

加鎖機制

樂觀鎖與悲觀鎖是兩種併發控制的思想，可用於解決丟失更新問題。

樂觀鎖

• 每次去取數據，都很樂觀，以爲不會出現併發問題。
• 所以，訪問、處理數據每次都不上鎖。
• 可是在更新的時候，再根據版本號或時間戳判斷是否有衝突，有則處理，無則提交事務。

悲觀鎖

• 每次去取數據，很悲觀，都以爲會被別人修改，會有併發問題。
• 所以，訪問、處理數據前就加排他鎖。
• 在整個數據處理過程當中鎖定數據，事務提交或回滾後才釋放鎖.

鎖粒度

• 表鎖： 開銷小，加鎖快；鎖定力度大，發生鎖衝突機率高，併發度最低;不會出現死鎖。
• 行鎖： 開銷大，加鎖慢；會出現死鎖；鎖定粒度小，發生鎖衝突的機率低，併發度高。
• 頁鎖： 開銷和加鎖速度介於表鎖和行鎖之間；會出現死鎖；鎖定粒度介於表鎖和行鎖之間，併發度通常

兼容性

共享鎖：

• 又稱讀鎖（S鎖）。
• 一個事務獲取了共享鎖，其餘事務能夠獲取共享鎖，不能獲取排他鎖，其餘事務能夠進行讀操做，不能進行寫操做。
• SELECT ... LOCK IN SHARE MODE 顯示加共享鎖。

排他鎖：

• 又稱寫鎖（X鎖）。
• 若是事務T對數據A加上排他鎖後，則其餘事務不能再對A加任任何類型的封鎖。獲准排他鎖的事務既能讀數據，又能修改數據。
• SELECT ... FOR UPDATE 顯示添加排他鎖。

鎖模式

• 記錄鎖： 在行相應的索引記錄上的鎖，鎖定一個行記錄
• gap鎖： 是在索引記錄間歇上的鎖,鎖定一個區間
• next-key鎖： 是記錄鎖和在此索引記錄以前的gap上的鎖的結合，鎖定行記錄+區間。
• 意向鎖 是爲了支持多種粒度鎖同時存在；

參考與感謝

• 《MySQL技術內幕》
• 《高性能MySql》
• MySQL InnoDB鎖機制全面解析分享 segmentfault.com/a/119000001…
• 數據庫兩大神器【索引和鎖】 juejin.im/post/5b55b8…
• InnoDB的邏輯存儲結構學習 blog.csdn.net/m0_37752084…
• MySQL索引背後的數據結構及算法原理 blog.codinglabs.org/articles/th…

我的公衆號

歡迎你們關注，你們一塊兒學習，一塊兒討論哈。