文章主要給大家介紹了關於MySQL InnoDB如何保證事務特性的相關資料，文中透過示例程式碼介紹的非常詳細，對大家學習或者使用MySQL具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧。
前言
如果有人問你“資料庫事務有哪些特性”？你可能會很快回答出原子性、一致性、隔離性、永續性即ACID特性。那麼你知道InnoDB如何保證這些事務特性的嗎？如果知道的話這篇文章就可以直接跳過不看啦(#^.^#)
先說結論：
- redo log重做日誌用來保證事務的永續性
- undo log回滾日誌保證事務的原子性
- undo log+redo log保證事務的一致性
- 鎖（共享、排他）用來保證事務的隔離性
重做日誌 redo log
重做日誌 redo log 分為兩部分：一部分是記憶體中的重做日誌緩衝（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
為了滿足事務的原子性，在操作任何資料之前，首先將資料備份到一個地方（這個儲存資料備份的地方稱為Undo Log），然後進行資料的修改。如果出現了錯誤或者使用者執行了 ROLLBACK語句，系統可以利用Undo Log中的備份將資料恢復到事務開始之前的狀態。
undo log實現多版本併發控制（MVCC）來輔助保證事務的隔離性。
回滾日誌不同於重做日誌，它是邏輯日誌，對資料庫的修改都邏輯的取消了。當事務回滾時，它實際上做的是與先前相反的工作。對於每個INSERT，InnoDB儲存引擎都會完成一個DELETE；對於每個UPDATE，InnoDB儲存引擎都會執行一個相反的UPDATE。
事務提交後並不能馬上刪除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執行緒進行最後的刪除。
鎖
事務的隔離性的實現原理就是鎖，因而隔離性也可以稱為併發控制、鎖等。事務的隔離性要求每個讀寫事務的物件對其他事務的操作物件能互相分離。再者，比如操作緩衝池中的LRU列表，刪除，新增、移動LRU列表中的元素，為了保證一致性那麼就要鎖的介入。
鎖的型別
InnoDB主要有2種鎖：行級鎖，意向鎖
行級鎖：
- 共享鎖（讀鎖 S），允許事務讀一行資料。事務拿到某一行記錄的共享S鎖，才可以讀取這一行，並阻止別的事務對其新增X鎖。共享鎖的目的是提高讀讀併發。
- 排它鎖（寫鎖 X），允許事務刪除一行資料或者更新一行資料。事務拿到某一行記錄的排它X鎖，才可以修改或者刪除這一行。排他鎖的目的是為了保證資料的一致性。
行級鎖中，除了S和S相容，其他都不相容。
意向鎖：
- 意向共享鎖（讀鎖 IS ），事務想要獲取一張表的幾行資料的共享鎖，事務在給一個資料行加共享鎖前必須先取得該表的IS鎖。
- 意向排他鎖（寫鎖 IX），事務想要獲取一張表中幾行資料的排它鎖，事務在給一個資料行加排他鎖前必須先取得該表的IX鎖。
解釋一下意向鎖
The main purpose of IX and IS locks is to show that someone is locking a row, or going to lock a row in the table.
意向鎖的主要用途是為了表達某個事務正在鎖定一行或者將要鎖定一行資料。e.g:事務A要對一行記錄r進行上X鎖，那麼InnoDB會先申請表的IX鎖，再鎖定記錄r的X鎖。在事務A完成之前，事務B想要來個全表操作，此時直接在表級別的IX就告訴事務B需要等待而不需要在表上判斷每一行是否有鎖。意向排它鎖存在的價值在於節約InnoDB對於鎖的定位和處理效能。另外注意了，除了全表掃描以外意向鎖都不會阻塞。
鎖的演算法
InnoDB有三種行鎖的演算法：
- Record Lock：單個行記錄上的鎖
- Gap Lock：間隙鎖，鎖定一個範圍，而非記錄本身
- Next-Key Lock：結合Gap Lock和Record Lock，鎖定一個範圍，並且鎖定記錄本身。主要解決的問題是REPEATABLE READ隔離級別下的幻讀。可以參考文章瞭解事務隔離級別的相關知識點。
這裡主要講一下Next-Key Lock，利用Next-key Lock鎖定的不是單個值而是一個範圍，他的目的就是為了阻止多個事務將記錄插入到同一範圍內從而導致幻讀。
注意了，如果走唯一索引，那麼Next-Key Lock會降級為Record Lock，即僅鎖住索引本身，而不是範圍。也就是說Next-Key Lock前置條件為事務隔離級別為RR且查詢的索引走的非唯一索引、主鍵索引。
下面我們用個例子詳細說一下。
首先建立一張表：
CREATE TABLE T (id int ,f_id int,PRIMARY KEY (id), KEY(f_id)) ENGINE=InnoDB DEFAULT CHARSET=utf8
insert into T SELECT 1,1;
insert into T SELECT 3,1;
insert into T SELECT 5,3;
insert into T SELECT 7,6;
insert into T SELECT 10,8;
時SQL語句走非唯一索引，因此使用Next-Key Locking加鎖，並且有2個索引，其需要分別進行鎖定。事務A執行如下語句：
SELECT * FROM T WHERE f_id = 3 FOR UPDATE
對於聚集索引，其僅對id等於5的索引加上Record Lock。而對於輔助索引，其加上Next-Key Lock，鎖定了範圍（1,3），特別需要注意的是，InnoDB儲存引擎還會對輔助索引下一個鍵值加上Gap Lock，即範圍（3.6）的鎖。
所以如果在新session中執行如下語句都會報錯[Err] 1205 - Lock wait timeout exceeded; try restarting transaction：
select * from T where id = 5 lock in share MODE -- 不能執行，因為事務A已經給id=5的值加上了X鎖，執行會被阻塞
INSERT INTO T SELECT 4,2 -- 不能執行，輔助索引的值為2，在（1,3）的範圍內，執行阻塞
INSERT INTO T SELECT 6,5 -- 不能執行，gap鎖會鎖住（3,6）的範圍，執行阻塞
總結此時想象一下，事務A鎖定了f_id =5 的記錄， 正常會有個gap lock，鎖住（5,6），那麼如果沒有（5,6）的gap鎖，那麼使用者可以插入索引 f_id 為5的記錄，這樣事務A再次查詢就會返回一個不同的記錄，也就導致了幻讀的產生。
同理，如果我們事務A執行的是select * from T where f_id = 10 FOR UPDATE,在表裡查不到資料，但是基於Next-Key Lock會鎖住（8，+∞），我們執行INSERT INTO T SELECT 6,11是無法插入成功的，這就從根本上解決了幻讀問題。
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，