MySQL實戰優化之InnoDB總體架構

1、InnoDB 更新數據得總體架構

每一個組件的做用說明：

用一條更新數據來講明每一個主鍵得做用：

update student set name = 'zhangsan' where id = 10

1. innodb得重要內存接口：緩衝池（Buffer Pool）

innodb存儲引擎中有一個重要得放在內存中得組件，就是緩衝池（Buffer Pool），這裏面會緩存不少得數據，以便於之後查詢數據得時候，若是在內存緩衝中有數據，就能夠直接從內存返回不須要查詢磁盤加載到內存緩衝中。

若是InnoDB存儲引擎須要執行一條更新語句得時候，好比上面那條數 id = 10 這條數據時候，首先會在緩衝中是否存在 id = 10 這條數據，若是不存在就直接從磁盤中把該條數據加載到緩衝裏來，並且會對這條數據加獨佔鎖。

2. undo 日誌文件：保證更新後的數據能夠回滾

假設 id = 10 這行數據的name原來是 zhangsan, 如今須要更新爲 lisi，那麼此時須要先把更新的原來的值 name = 'zhangsan' 和 id = 10 這些信息，寫入到undo日誌文件中，若是在後面的操做出現異常，須要作回滾數據就會從undo日誌文件中加載回滾。

3. 更新Buffer Pool中的緩衝數據

當咱們把要更新的那行數據從磁盤文件加載到緩衝池，同時對該行數據枷鎖後把更新前的舊值寫入到undo日誌文件以後，舊能夠正式開始更新這行記錄了，先更新緩衝池中的記錄，此時這行數據是髒數據。由於磁盤上的依舊是 name 的值是zhangsan，內存中的已是lisi因此說是髒數據。

4. Redo Log buffer:防止Mysql服務宕機後，保證數據不被丟失。

在buffer pool 中修改了數據後，咱們必須把對內存所做的修改寫入到一個Redo Log Buffer的內存緩衝區中，這個緩衝區是用於存放redo日誌的。所謂的redo日誌，就是記錄下來對數據作了什麼修改，好比對 id = 10 這行記錄修改了name字段的值爲lisi，這就是一條日誌。

在提交事物的時候會將redo日誌寫入到磁盤中（順序寫入），有一下集中方式寫入：

innodb_flush_log_at_trx_commit = 1:不寫入磁盤

innodb_flush_log_at_trx_commit = 2:提交事務的時候刷盤

innodb_flush_log_at_trx_commit = 3:寫入系統的os再定時刷入磁盤

通常使用的是第二種。

5. binglong日誌

binglog日誌是mysql server 服務的日誌，叫作歸檔日誌，他裏面記錄的是邏輯行的日誌，相似於 對 srtudent 表中的 id = 10 這行數據作了更新操做，更新後的值是什麼。

在提交事務的時候須要binglog日誌寫入到磁盤中，寫入的策略以下：

sync_binglog = 0:提交事務時寫入系統緩衝在定時刷入磁盤

sync_binglog = 1:提交事務時寫入磁盤。

 

總結innodb存儲引擎作一次跟新的架構原理：

你們經過一次更新數據的流程，就能夠清晰地看到，InnoDB存儲引擎主要就是包含了一些buffer pool redo log buffer等內存裏的緩存數據，同時還包含了一些undo日誌文件，redo日誌文件等東西，同時mysqlserver本身還有binlog日誌文件

在你執行更新的時候，每條SQL語句，都會對應修改buffer pool裏的緩存數據、寫undo日誌、寫redo log buffer幾個步驟

可是當你提交事務的時候，必定會把redolog刷入磁盤，binloq刷入磁盤，完成redolog中的事務commit標記;最後後臺的1O線程會隨機的把buffer pool裏的髒數據刷入磁盤裏去

 

面試題：

1. 執行更新操做的時候，爲何不精細修改磁盤上的數據？

2. 若是保證msyql服務宕機後數據更新後的數據不丟失?