一.背景
? ? 了解鎖機(jī)制能讓我們開發(fā)更加高效的程序竞帽，最小化鎖帶來的性能開銷析显。
二.鎖概念
? ? 鎖是存儲(chǔ)引擎為了實(shí)現(xiàn)共享資源并發(fā)訪問的一種管理機(jī)制來保證數(shù)據(jù)的一致性和完整性穿撮。
先整體看下鎖的使用情況
show status like 'innodb_row_lock%';
current_waits:代表正在等待的線程的數(shù)量沈矿。（注意是線程的數(shù)量，也就是事務(wù)數(shù)，不是加鎖的數(shù)量）
lock_waits:代表歷史上等待線程的數(shù)量余寥。（同一個(gè)線程嘗試多次會(huì)記錄多次）
其他幾個(gè)值根據(jù)字面意思就能看出來栈幸。
三.innodb中鎖的類型
? ?共享鎖：對(duì)一行數(shù)據(jù)加的只讀鎖。(意味著此條記錄只允許被讀寓落，不許被修改)
? ?排它鎖：對(duì)一行數(shù)據(jù)加的排它鎖。(意味著此條記錄不許其他線程加任何鎖）
? ?注意：共享鎖(S)和排它鎖(X)只可以對(duì)一行記錄加鎖。
? ?就是因?yàn)镾和X鎖都只針對(duì)記錄糠排，而對(duì)于一些操作如alter table僅僅想知道這種表現(xiàn)在有沒有數(shù)據(jù)被修改ing，所以為了處理這類操作引入了意向鎖(Intention Lock)超升。
? ?要為一行記錄加S或X鎖入宦，依次要給庫、表室琢、頁加對(duì)應(yīng)的IS或IX鎖乾闰，最后才對(duì)行加S或X鎖。
四.直觀感受鎖
?我們先來看下實(shí)踐盈滴，后面再詳細(xì)的分析理論涯肩。
下面分別查看當(dāng)前鎖使用情況轿钠。
select * from information_schema.innodb_trx;--當(dāng)前未提交事務(wù)的狀態(tài)
select * from information_schema.innodb_locks;--當(dāng)前正在爭(zhēng)奪的鎖
select * from information_schema.innodb_lock_waits;--當(dāng)前等待的鎖
1>.場(chǎng)景一：模擬單個(gè)事務(wù)未提交
? ?1.使用root用戶登錄
? ? ?select * from information_schema.innodb_trx;--當(dāng)前未提交事務(wù)的狀態(tài)
這張表主要記錄了當(dāng)前事務(wù)的狀態(tài)，開始時(shí)間病苗，權(quán)重(反映鎖住的行數(shù)疗垛，死鎖回滾權(quán)重小的)，線程id硫朦。
這時(shí)候贷腕，其他兩張表因?yàn)闆]有競(jìng)爭(zhēng)所以沒有數(shù)據(jù)。
結(jié)論：正在進(jìn)行的事務(wù)咬展，可以通過表1去查看開始的時(shí)間泽裳，權(quán)重等信息。
2>.場(chǎng)景二：事務(wù)1加X鎖未提交破婆，事務(wù)2修改同一行的數(shù)據(jù)涮总。
圖三因?yàn)槌瑫r(shí)回滾了，重新提交的荠割，所以事務(wù)id+1了妹卿。應(yīng)該是10872。
表2：可以看出存在競(jìng)爭(zhēng)的鎖的情況蔑鹦。
表3：可以看出阻塞的和等待的事物id夺克。
結(jié)論：通過這3張表，我們可以分析出嚎朽，當(dāng)前鎖的基本情況铺纽。
五.行鎖的3種算法概念
innodb鎖的三種算法：
1.record lock 加在索引上
2.Gap lock ReadRepeated隔離級(jí)別加在索引的范圍上，但不包含本身
3.next-key lock 鎖定范圍和記錄本身哟忍，在讀取已刪除的數(shù)據(jù)需要加這個(gè)鎖狡门，RR下默認(rèn)使用這種鎖，這種鎖其實(shí)就是上面兩種鎖的組合锅很，對(duì)記錄加next-key為(],對(duì)右邊加gap鎖其馏。
在使用唯一索引時(shí)降級(jí)為record lock而不是next
