[TOC] Mysql中日志還是挺多的，主要包含以下幾個常用的日志： 1. **binlog**：歸檔日志， Server層的日志。 2. **redo log**：重做日志，InnoDB存儲引擎層的日志。 3. **undo log**：回滾日志，提供回滾操作，InnoDB存儲引擎層的日志。 4. **relay log**：中繼日志，主從復制原理日志。 5. **slow_query_log**：慢查詢日志，用于慢sql。 * redo log重做日志用來保證事務的持久性 * undo log回滾日志 保證事務的原子性 * undo log+redo log保證事務的一致性 * 鎖（共享、排他）用來保證事務的隔離性 ## binlog binlog稱為歸檔日志，是邏輯上的日志，它屬于Mysql的Server層面的日志，記錄著sql的原始邏輯 有三種格式,statement,row和mixed. * statement模式下,記錄單元為語句.即每一個sql造成的影響會記錄.由于sql的執行是有上下文的,因此在保存的時候需要保存相關的信息,同時還有一些使用了函數之類的語句無法被記錄復制. * row級別下,記錄單元為每一行的改動,基本是可以全部記下來但是由于很多操作,會導致大量行的改動(比如alter table),因此這種模式的文件保存的信息太多,日志量太大. * mixed. 一種折中的方案,普通操作使用statement記錄,當無法使用statement的時候使用row. 此外,新版的MySQL中對row級別也做了一些優化,當表結構發生變化的時候,會記錄語句而不是逐行記錄. ## redo log----保證事務的持久性 >redo log日志也叫做WAL技術（Write- Ahead Logging），他是一種先寫日志，并更新內存，最后再更新磁盤的技術，為了就是減少sql執行期間的數據庫io操作，并且更新磁盤往往是在Mysql比較閑的時候，這樣就大大減輕了Mysql的壓力。 redo log是固定大小，是物理日志，屬于InnoDB引擎的，并且寫redo log是環狀寫日志的形式：  check point記錄擦除的位置，因為redo log是固定大小，所以當redo log滿的時候，也就是write pos追上check point的時候，需要清除redo log的部分數據，清除的數據會被持久化到磁盤中，然后將check point向前移動。 redo log日志實現了即使在數據庫出現異常宕機的時候，重啟后之前的記錄也不會丟失，這就是crash-safe能力。 ### 組成 分為兩部分：一部分是內存中的重做日志緩沖（redo log buffer），是易丟失的；二部分是重做日志文件（redo log file），是持久的。InnoDB通過Force Log at Commit機制來實現持久性，當commit時，必須先將事務的所有日志寫到重做日志文件進行持久化，待commit操作完成才算完成。 InnoDB在下面情況下會將重做日志緩沖的內容寫入重做日志文件： * master thread 每一秒將重做日志緩沖刷新到重做日志文件; * 每個事務提交時 * 當重做日志緩沖池剩余空間小于1/2時 為了確保每次日志都寫入重做日志文件，在每次將日志緩沖寫入重做日志文件后，InnoDB存儲引擎都需要調用一次fsync（刷盤）操作。但這也不是絕對的。用戶可以通過修改innodb\_flush\_log\_at\_trx\_commoit參數來控制重做日志刷新到磁盤的策略，這個可以作為大量事務提交時的優化點。 * 1參數默認值，表示事務提交時必須調用一次fsync操作。 * 0表示事務提交時，重做日志緩存并不立即寫入重做日志文件，而是隨著Master Thread的間隔進行fsync操作。 * 2表示事務提交時將重做日志寫入重做日志文件，但僅寫入文件系統的緩存中，不進行fsync操作。 fsync的效率取決于磁盤的性能，因此磁盤的性能決定了事務提交的性能，也就是數據庫的性能。**所以如果有人問你如何優化Mysql數據庫的時候別忘了有硬件這一條，讓他們提升硬盤配置，換SSD固態硬盤** 重做日志都是以512字節進行存儲的，稱之為重做日志塊，與磁盤扇區大小一致，這意味著重做日志的寫入可以保證原子性，不需要doublewrite技術。它有以下3個特性： * 重做日志是在InnoDB層產生的 * 重做日志是物理格式日志，記錄的是對每個頁的修改 * 重做日志在事務進行中不斷被寫入，而且是順序寫入 ## undo log-----保證事務的原子性 它是邏輯日志。可以認為當delete一條記錄時，undo log中會記錄一條對應的insert記錄，反之亦然，當update一條記錄時，它記錄一條對應相反的update記錄。 **作用** 　　保存了事務發生之前的數據的一個版本，可以用于回滾，同時可以提供多版本并發控制下的讀（MVCC），也即非鎖定讀 **內容** 　　邏輯格式的日志，在執行undo的時候，僅僅是將數據從邏輯上恢復至事務之前的狀態，而不是從物理頁面上操作實現的，這一點是不同于redo log的。 **什么時候產生** 　　事務開始之前，將當前是的版本生成undo log，undo 也會產生 redo 來保證undo log的可靠性 **什么時候釋放** 　　當事務提交之后，undo log并不能立馬被刪除， 　　而是放入待清理的鏈表，由purge線程判斷是否由其他事務在使用undo段中表的上一個事務之前的版本信息，決定是否可以清理undo log的日志空間。 ### 實現的功能 1.實現事務回滾 2.實現MVCC >事務提交后并不能馬上刪除undo log，這是因為可能還有其他事務需要通過undo log 來得到行記錄之前的版本。故事務提交時將undo log 放入一個鏈表中，是否可以刪除undo log 根據操作不同分以下2種情況： >* Insert undo log： insert操作的記錄，只對事務本身可見，對其他事務不可見(這是事務隔離性的要求),故該undo log可以在事務提交后直接刪除。不需要進行 purge操作。 >* update undo log：記錄的是對 delete和 update操作產生的 undo log。該undo log可能需要提供MVCC機制，因此不能在事務提交時就進行刪除。提交時放入undo log鏈表,等待 purge線程進行最后的刪除。 ## relay log relay log中繼日志用于實現主從復制 主從復制中分為「主服務器（master）「和」從服務器（slave）」，「主服務器負責寫，而從服務器負責讀」，Mysql的主從復制的過程是一個「異步的過程」。  Mysql的主從復制中主要有三個線程：master（binlog dump thread）、slave（I/O thread 、SQL thread），Master一條線程和Slave中的兩條線程。 master（binlog dump thread）主要負責Master庫中有數據更新的時候，會按照binlog格式，將更新的事件類型寫入到主庫的binlog文件中。 并且，Master會創建log dump線程通知Slave主庫中存在數據更新，這就是為什么主庫的binlog日志一定要開啟的原因。 I/O thread線程在Slave中創建，該線程用于請求Master，Master會返回binlog的名稱以及當前數據更新的位置、binlog文件位置的副本。 然后，將binlog保存在 「relay log（中繼日志）」 中，中繼日志也是記錄數據更新的信息。 SQL線程也是在Slave中創建的，當Slave檢測到中繼日志有更新，就會將更新的內容同步到Slave數據庫中，這樣就保證了主從的數據的同步。 以上就是主從復制的過程，當然，主從復制的過程有不同的策略方式進行數據的同步，主要包含以下幾種： 1. 「全同步策略」：Master會等待所有的Slave都回應后才會提交，這個主從的同步會受到嚴重的影響。 2. 「半同步策略」：Master至少會等待一個Slave回應后提交。 3. 「異步策略」：Master不用等待Slave回應就可以提交。 4. 「延遲策略」：Slave要落后于Master指定的時間。 ## slow_query_log 在mysql中有一個動態參數long_query_time表示慢查詢的閾值，表示當執行的sql超過這個這個參數的時間，就數據慢查詢的范圍就會將此紀錄存入該日志中，該值默認為10，通以下命令進行查看。  一般情況下是關閉的  通過命令SET GLOBAL slow_query_log=ON將該功能開啟