MySQL中InnoDB鎖機制分析

本篇內容介紹了“MySQL中InnoDB鎖機制分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

一 前言
本文介紹另外兩種鎖 Insert Intention Locks和AUTO-INC Locks
二 常見的鎖類型
2.1 根據鎖持有的時間粒度，分為
1. 內存級別：類似mutex，很快釋放
2. 語句級別：statement結束，釋放
3. 事務級別：transaction提交或者回滾才釋放
4. 會話級別：session級別，連接斷開才釋放

2.2  AUTO-INC lock
AUTO-INC lock是一個特殊的表級鎖，當一個事務向含有自增字段的表插入數據時 ，該事務會獲取一個AUTO-INC lock，其他事務必須等待直到已經獲取鎖的insert 語句結束。因此,多個并發事務不能同時獲取同一個表上面的AUTO-INC lock,如果持有AUTO-INC鎖太長時間可能會影響到數據庫性能(比如INSERT INTO t1... SELECT ... FROM t2這類語句)或者死鎖.
鑒于AUTO-INC 鎖的特性,MySQL 5.1.22 通過新增參數 innodb_autoinc_lock_mode 來控制自增序列的算法。該參數可以設置為0,1,2.
在學習innodb_autoinc_lock_mode之前，我們先了解insert語句的類型
1 Simple inserts
  能夠事先確定具體行數的insert語句，比如 insert into tab values()...(); replace 等等。 INSERT ... ON DUPLICATE KEY UPDATE和還有子查詢的insert 語句除外。
2 Bulk inserts
  和Simple inserts對立，事先不能確定插入行數的 insert/replace語句 ，insert ... select ;replace ...select; load data into table .. 這種情況下Innodb在執行具體的行的時候 會為每一行單獨分配一個auto_increment 值。
3  Mixed-mode inserts
  該情形是 Simple inserts 模式中，有些insert指定了 自增字段的具體值，有些沒有指定。比如:
INSERT INTO t1 (c1,c2) VALUES (1,'a'), (NULL,'b'), (5,'c'), (NULL,'d');
INSERT ... ON DUPLICATE KEY UPDATE

接下來我們再看MySQL對auto_increment 的優化模式。
innodb_autoinc_lock_mode=0，是傳統的方式。InnoDB會在分配前給表加上AUTO_INC鎖，并在SQL結束時釋放掉。該模式保證了在STATEMENT復制模式下，備庫執行類似INSERT … SELECT這樣的語句時的一致性，因為這樣的語句在執行時無法確定到底有多少條記錄，只有在執行過程中不允許別的會話分配自增值，才能確保主備一致。
很顯然這種鎖模式非常影響并發插入的性能，但卻保證了一條SQL內自增值分配的連續性。
innodb_autoinc_lock_mode=1 ，這個是InnoDB的默認值。該模式下對于Simple inserts，InnoDB會先加一個 autoinc_mutex鎖，然后去判斷表上是否有別的線程加了LOCK_AUTO_INC鎖，如果有的話，釋放autoinc_mutex，并使用傳統的加鎖模式。否則，在預留本次插入需要的自增值之后，就快速的將autoinc_mutex釋放掉。很顯然，對于普通的并發INSERT操作，都是無需加LOCK_AUTO_INC鎖的。因此該模式提高了系統并發性；
innodb_autoinc_lock_mode=2，這種模式下只在分配時加個mutex即可，很快就釋放，不會像值為1那樣在某些場景下會退化到傳統模式。因此設為2不能保證批量插入的復制安全性。

2.3  Insert Intention Locks
     插入意向鎖是gap 鎖的一種，只是針對insert。當并發事務多條insert 插入同一個GAP,如果他們不是插入同一行記錄，會話之間并不會相互等待。例如索引記錄刪 有 12 ，17 兩個記錄，兩個會話同時插入記錄13，15，他們會分別為(12,17)加上GAP鎖，但相互之間并不沖突（因為插入的記錄不沖突）。
     當向某個數據頁中插入一條記錄時，總是會調用函數lock_rec_insert_check_and_lock進行鎖檢查（構建索引時的數據插入除外），會去檢查當前插入位置的下一條記錄上是否存在鎖對象，這里的下一條記錄不是指的物理連續，而是按照邏輯順序的下一條記錄。
如果下一條記錄上不存在鎖對象：若記錄是二級索引上的，先更新二級索引頁上的最大事務ID為當前事務的ID；直接返回成功。
如果下一條記錄上存在鎖對象，就需要判斷該鎖對象是否鎖住了GAP。如果GAP被鎖住了，并判定和插入意向GAP鎖沖突，當前操作就需要等待，加的鎖類型為LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION，并進入等待狀態。但是插入意向鎖之間并不互斥。這意味著在同一個GAP里可能有多個申請插入意向鎖的會話。

“MySQL中InnoDB鎖機制分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！