一、鎖的型別
InnoDB 存盤引擎 lock 的物件是事務，用來鎖定的是資料庫中的物件，如表、頁、行，并且一般 lock 的物件僅在事務 commit 或 rollback 后進行釋放（不同事務隔離級別釋放的時間可能不同），
InnoDB 存盤引擎實作了如下兩種標準的行級鎖，其中，X 鎖與任何的鎖都不兼容，而 S 鎖僅和 S 鎖兼容（兼容指對同一記錄行的兼容性情況）
- 共享鎖（S Lock），允許事務讀一行資料；
- 排他鎖（X Lock），允許事務洗掉或更新一行資料；
InnoDB 存盤引擎除了行鎖以外，還有表鎖，通常也稱為意向鎖，其設計目的主要是為了在一個事務中揭示下一行將被請求的鎖型別，其支持兩種意向鎖：
- 意向共享鎖（IS Lock），事務想要獲得一張表中某幾行的共享鎖
- 意向排他鎖（IX Lock），事務想要獲得一張表中某幾行的排他鎖
通過 information_schema 架構下的 INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS 三張表，用戶可以更簡單的監控當前事務并分析可能存在的鎖問題，
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
二、鎖的演算法
InnoDB 存盤引擎有三種行鎖的演算法，其分別是：
- Record Lock：單個行記錄上的鎖
- Gap Lock：間隙鎖，鎖定一個范圍，但不包含記錄本身
- Next-Key Lock：Record Lock + Gap Lock，鎖定一個范圍，并且鎖定記錄本身
Record Lock 總是會去鎖住索引記錄，InnoDB 存盤引擎會使用聚簇索引來進行鎖定，
Gap Lock 的作用是為了阻止多個事務將記錄插入到同一個范圍內，因為這會導致幻讀問題（phantom Problem）的產生，用戶可以通過以下兩種方式來顯式地關閉 Gap Lock：
- 將事務的隔離級別設定為 READ COMMITTED
- 將引數 innodb_locks_unsafe_for_binlog 設定為 1
Next-Key Lock 是結合了 Gap Lock 和 Record Lock 的一種索引演算法，這種鎖定技術，不止鎖定記錄本身，還鎖定一個范圍，
InnoDB 對于行的查詢默認是采用 Next-Key Lock 演算法，當查詢的索引含有唯一屬性時（主鍵索引、唯一索引），InnoDB 存盤引擎會對 Next-Key Lock 進行優化，將其降級為 Record Lock；而對于輔助索引，不僅會對索引列加 Record Lock ，還會對索引列前后的鍵值范圍加上 Gap Lock，
Phantom Problem：幻讀問題，指在同一事務下，連續執行兩次同樣的 SQL 陳述句可能導致不同的結果，第二次的 SQL 陳述句可能會回傳之前不存在的行，
1. 聚簇索引的加鎖情況
select * from students where id = 20 for update;
2. 唯一索引的加鎖情況
select * from students where num = 135 for update;
3. 二級索引的加鎖情況
select * from students where score= 91 for update;
4. 無索引的加鎖情況
select * from students where age = 22 for update;
三、鎖的問題
-
Dirty Read 臟讀：一個事務讀到了另一個未提交的事務寫的資料，這顯然違反了資料庫的隔離性，
-
Non-Repeatable Read 不可重復讀：一個事務內多次讀取同一資料集合，可能兩次讀到的資料是不一樣的，不可重復讀和臟讀的區別是：臟讀是讀到未提交的資料，而不可重復讀讀到的卻是已經提交的資料，這顯然違反了資料庫的一致性，
-
Phantom Problem 幻讀 ：幻讀問題，指在同一事務下，連續執行兩次同樣的 SQL 陳述句可能導致不同的結果，第二次的 SQL 陳述句可能會回傳之前不存在的行，幻讀是比不可重復讀高一個級別的錯誤，讀取同一條資料發現跟剛才是一樣的，只有讀取一堆資料發現忽然多了一個，或者少了一個，像是產生了幻覺，
-
Lost Update 更新丟失
a. 第一類更新丟失，回滾覆寫：撤消一個事務時，在該事務內的寫操作要回滾，把其它已提交的事務寫入的資料覆寫了，
b. 第二類更新丟失，提交覆寫：提交一個事務時，寫操作依賴于事務內讀到的資料，讀發生在其他事務提交前，寫發生在其他事務提交后，把其他已提交的事務寫入的資料覆寫了，這是不可重復讀的特例，
為了解決多個事務并發會引發的鎖問題，資料庫系統提供了四種事務隔離級別供用戶選擇，
- Read Uncommitted 讀未提交：不允許第一類更新丟失，允許臟讀，不隔離事務，
- Read Committed 讀已提交：不允許臟讀，允許不可重復讀（即允許第二類更新丟失），
- Repeatable Read 可重復讀：不允許不可重復讀（即不允許第二類更新丟失），但可能出現幻讀，
- Serializable 串行化：所有的增刪改查串行執行，
為什么 MYSQL 默認使用 Repeatable Read 隔離級別？這跟資料庫的主從復制有關，MYSQL 的主從復制是基于 binlog 復制的，而 binlog 有三種格式，分別為：
- statement：記錄的是修改 SQL 陳述句
- row：記錄的是每行實際資料的變更
- mixed：statement 和 row 模式的混合
那 MYSQL 在 5.0 這個版本以前，binlog 只支持 statement 這種格式！而這種格式在讀已提交（Read Commited）這個隔離級別下主從復制是有 bug 的，因此 Mysql 將可重復讀（Repeatable Read）作為默認的隔離級別，
怎么解決 Read Committed 隔離級別下，主從復制有問題的 bug？首先得解釋下這個 bug，在 master 上執行的順序為先刪后插，若此時 binlog 為 statement 格式，它記錄的順序為先插后刪，slave 同步的是 binglog，因此 slave 執行的順序和主機不一致，就會出現主從不一致，怎么解決這個 bug 呢？
- 隔離級別設為可重復讀（Repeatable Read），在該隔離級別下引入間隙鎖（GAP LOCK），在執行 DELETE 陳述句時，會鎖住間隙，那么執行 INSERT 陳述句就會阻塞住，
- 將 binglog 的格式修改為 row 格式，此時是基于行的復制，自然就不會出現 sql 執行順序不一樣的問題（這個格式在 MYSQL 5.1 版本才開始引入），
四、其它
-
在 InnoDB 存盤引擎中，引數
innodb_lock_wait_timeout用來控制等待得時間（默認是 50 秒），innodb_rollback_on_timeout用來設定是否在等待超時時對進行中的事務進行回滾操作（默認是 OFF，代表不回滾） -
InnoDB 存盤引擎在大部分情況下都不會對例外進行回滾（死鎖除外），因此用戶必須判斷是否需要 COMMIT 還是 ROLLBACK，之后再進行下一步的操作，
-
InnoDB 存盤引擎通過 wait-for graph（等待圖）的方式來進行死鎖檢測，wait-for graph 是一種較為主動的死鎖檢測機制，在每個事務請求鎖并發生等待時都會判斷是否存在回路，若存在則有死鎖，通常來說 InnoDB 存盤引擎選擇回滾 undo 量最小的事務，
-
InnoDB 存盤引擎不存在鎖升級的問題，因為其不是根據每個記錄來產生行鎖的，相反，其根據每個事務訪問的每個頁對鎖進行管理的，采用的是位圖的方式，因此不管一個事務鎖住頁中的一個記錄還是多個記錄，其開銷通常是一致的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/245146.html
標籤：其他