MySQL中邏輯分層簡單介紹
下面是MySQL的邏輯分層圖：
- 連接層：連接與線程處理，這一層並不是MySQL獨有，一般的基於C/S架構的都有類似組件，比如連接處理、授權認證、安全等。
- 服務層：包括緩存查詢、解析器、優化器，這一部分是MySQL核心功能，包括解析、優化SQL語句，查詢緩存目錄，內置函數（日期、時間、加密等函數）的實現。
- 引擎層：負責數據存儲，存儲引擎的不同，存儲方式、數據格式、提取方式等都不相同，這一部分也是很大影響數據存儲與提取的性能的；對存儲層的抽象。
- 存儲層：存儲數據，文件系統
redo log、binlog、undo log 區別與作用
redolog和undolog只存在於innodb中，這兩個日志在innodb中統稱為事務日志。undolog用於回滾，redolog用於前滾
- 前滾：
事務提交之后，部分數據寫入了磁盤，但是還有部分數據存在臟頁上，並沒有寫入磁盤。此時設備宕機，沒有寫入磁盤的數據丟失。就要依賴redolog來恢復這部分數據 - 回滾：
事務還未提交，改動並沒有完全生效，但是記錄已經被修改。此時設備宕機，數據是有問題的，就要依賴undolog回滾改動
bin log
歸檔日志（二進制日志）(Server 層日志)
作用：用於復制，在主從復制中，從庫利用主庫上的binlog進行重播，實現主從同步。
用於數據庫的基於時間點的還原。
內容：邏輯格式的日志，記錄了數據庫表結構和表數據變更，比如update/delete/insert/truncate/create。它不會記錄select（因為這沒有對表沒有進行變更），可以簡單認為就是sql語句。
binlog 有三種模式：Statement（基於 SQL 語句的復制）、Row（基於行的復制） 以及 Mixed（混合模式）
redo log
重做日志（引擎層日志）
- 作用
確保事務的持久性。防止在發生故障的時間點，尚有臟頁未寫入磁盤，在重啟mysql服務的時候，根據redo log進行重做，從而達到事務的持久性這一特性。 - 內容
物理格式的日志，記錄的是物理數據頁面的修改的信息，其redo log是順序寫入redo log file的物理文件中去的。 - 產生時間：
事務開始之后就產生redo log，redo log的落盤並不是隨着事務的提交才寫入的，而是在事務的執行過程中，便開始寫入redo log文件中 - 釋放時間：
當對應事務的臟頁寫入到磁盤之后，redo log的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋） - 對應的本地物理文件：
默認情況下，對應的物理文件位於數據庫的data目錄下的ib_logfile1&ib_logfile2
innodb_log_group_home_dir 指定日志文件組所在的路徑，默認./ ，表示在數據庫的數據目錄下。
innodb_log_files_in_group 指定重做日志文件組中文件的數量，默認2
關於文件的大小和數量，由以下兩個參數配置：
innodb_log_file_size 重做日志文件的大小
innodb_mirrored_log_groups 指定了日志鏡像文件組的數量，默認1
undo log
回滾日志（引擎層）
- 作用：
Undo 記錄某 數據 被修改 前 的值，可以用來在事務失敗時進行rollback，用於回滾，同時可以提供多版本並發控制下的讀（MVCC），也即非鎖定讀 - 內容：
邏輯格式的日志，在執行undo的時候，僅僅是將數據從邏輯上恢復至事務之前的狀態，記錄數據修改被修改前的值 - 釋放時間
當事務提交之后，undo log並不能立馬被刪除,而是會被放到待清理鏈表中,待判斷沒有事物用到該版本的信息時才可以清理相應undolog