MySQL中InnoDB鎖機制分析

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

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網(wǎng)站設計制作、成都網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的微山網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

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

2.2  AUTO-INC lock
AUTO-INC lock是一個特殊的表級鎖，當一個事務向含有自增字段的表插入數(shù)據(jù)時 ，該事務會獲取一個AUTO-INC lock，其他事務必須等待直到已經(jīng)獲取鎖的insert 語句結束。因此,多個并發(fā)事務不能同時獲取同一個表上面的AUTO-INC lock,如果持有AUTO-INC鎖太長時間可能會影響到數(shù)據(jù)庫性能(比如INSERT INTO t1... SELECT ... FROM t2這類語句)或者死鎖.
鑒于AUTO-INC 鎖的特性,MySQL 5.1.22 通過新增參數(shù) innodb_autoinc_lock_mode 來控制自增序列的算法。該參數(shù)可以設置為0,1,2.
在學習innodb_autoinc_lock_mode之前，我們先了解insert語句的類型
1 Simple inserts
  能夠事先確定具體行數(shù)的insert語句，比如 insert into tab values()...(); replace 等等。 INSERT ... ON DUPLICATE KEY UPDATE和還有子查詢的insert 語句除外。
2 Bulk inserts
  和Simple inserts對立，事先不能確定插入行數(shù)的 insert/replace語句 ，insert ... select ;replace ...select; load data into table .. 這種情況下Innodb在執(zhí)行具體的行的時候 會為每一行單獨分配一個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 的優(yōu)化模式。
innodb_autoinc_lock_mode=0，是傳統(tǒng)的方式。InnoDB會在分配前給表加上AUTO_INC鎖，并在SQL結束時釋放掉。該模式保證了在STATEMENT復制模式下，備庫執(zhí)行類似INSERT … SELECT這樣的語句時的一致性，因為這樣的語句在執(zhí)行時無法確定到底有多少條記錄，只有在執(zhí)行過程中不允許別的會話分配自增值，才能確保主備一致。
很顯然這種鎖模式非常影響并發(fā)插入的性能，但卻保證了一條SQL內(nèi)自增值分配的連續(xù)性。
innodb_autoinc_lock_mode=1，這個是InnoDB的默認值。該模式下對于Simple inserts，InnoDB會先加一個 autoinc_mutex鎖，然后去判斷表上是否有別的線程加了LOCK_AUTO_INC鎖，如果有的話，釋放autoinc_mutex，并使用傳統(tǒng)的加鎖模式。否則，在預留本次插入需要的自增值之后，就快速的將autoinc_mutex釋放掉。很顯然，對于普通的并發(fā)INSERT操作，都是無需加LOCK_AUTO_INC鎖的。因此該模式提高了系統(tǒng)并發(fā)性；
innodb_autoinc_lock_mode=2，這種模式下只在分配時加個mutex即可，很快就釋放，不會像值為1那樣在某些場景下會退化到傳統(tǒng)模式。因此設為2不能保證批量插入的復制安全性。

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

“MySQL中InnoDB鎖機制分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

當前標題：MySQL中InnoDB鎖機制分析
當前地址：http://www.muchs.cn/article16/gdgddg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、品牌網(wǎng)站設計、微信小程序、關鍵詞優(yōu)化、用戶體驗、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)