Mysql 鎖類型

一头遭、鎖類型介紹：

MySQL有三種鎖的級別：頁級寓免、表級、行級计维。

表級鎖：開銷小袜香，加鎖快；不會出現(xiàn)死鎖鲫惶；鎖定粒度大蜈首，發(fā)生鎖沖突的概率最高,并發(fā)度最低。
行級鎖：開銷大，加鎖慢欢策；會出現(xiàn)死鎖吆寨；鎖定粒度最小，發(fā)生鎖沖突的概率最低,并發(fā)度也最高踩寇。
頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間啄清；會出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間姑荷，并發(fā)度一般

算法：

next KeyLocks鎖，同時鎖住記錄(數(shù)據(jù))缩擂，并且鎖住記錄前面的Gap
Gap鎖鼠冕，不鎖記錄，僅僅記錄前面的Gap
Recordlock鎖（鎖數(shù)據(jù)胯盯，不鎖Gap）
所以其實(shí) Next-KeyLocks=Gap鎖+ Recordlock鎖

二懈费、死鎖產(chǎn)生原因和示例

1、產(chǎn)生原因：

所謂死鎖：是指兩個或兩個以上的進(jìn)程在執(zhí)行過程中,因爭奪資源而造成的一種互相等待的現(xiàn)象,若無外力作用博脑，它們都將無法推進(jìn)下去.此時稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖憎乙，這些永遠(yuǎn)在互相等待的進(jìn)程稱為死鎖進(jìn)程。表級鎖不會產(chǎn)生死鎖.所以解決死鎖主要還是針對于最常用的InnoDB叉趣。

死鎖的關(guān)鍵在于：兩個(或以上)的Session加鎖的順序不一致泞边。

那么對應(yīng)的解決死鎖問題的關(guān)鍵就是：讓不同的session加鎖有次序

2、產(chǎn)生示例：

案例一

需求：將投資的錢拆成幾份隨機(jī)分配給借款人疗杉。

起初業(yè)務(wù)程序思路是這樣的：

投資人投資后阵谚，將金額隨機(jī)分為幾份，然后隨機(jī)從借款人表里面選幾個烟具，然后通過一條條select for update 去更新借款人表里面的余額等梢什。

例如兩個用戶同時投資，A用戶金額隨機(jī)分為2份朝聋，分給借款人1嗡午，2

B用戶金額隨機(jī)分為2份，分給借款人2冀痕，1

由于加鎖的順序不一樣荔睹，死鎖當(dāng)然很快就出現(xiàn)了。

對于這個問題的改進(jìn)很簡單言蛇，直接把所有分配到的借款人直接一次鎖住就行了应媚。

Select * from xxx where id in (xx,xx,xx) for update

在in里面的列表值mysql是會自動從小到大排序，加鎖也是一條條從小到大加的鎖

例如（以下會話id為主鍵）：

Session1:

mysql> select * from t3 where id in (8,9) for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
|  8 | WA     | f    | 2016-03-02 11:36:30 |
|  9 | JX     | f    | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+
rows in set (0.04 sec)

Session2:

select * from t3 where id in (10,8,5) for update;

鎖等待中……

其實(shí)這個時候id=10這條記錄沒有被鎖住的猜极，但id=5的記錄已經(jīng)被鎖住了中姜，鎖的等待在id=8的這里不信請看

Session3:

mysql> select * from t3 where id=5 for update;

鎖等待中

Session4:

mysql> select * from t3 where id=10 for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
| 10 | JB     | g    | 2016-03-10 11:45:05 |
+----+--------+------+---------------------+
row in set (0.00 sec)

在其它session中id=5是加不了鎖的，但是id=10是可以加上鎖的。

案例二

在開發(fā)中丢胚，經(jīng)常會做這類的判斷需求：根據(jù)字段值查詢（有索引）翩瓜，如果不存在，則插入携龟；否則更新兔跌。

以id為主鍵為例，目前還沒有id=22的行

Session1:

select * from t3 where id=22 for update;

Empty set (0.00 sec)

session2:

select * from t3 where id=23  for update;Empty set (0.00 sec)

Session1:

insert into t3 values(22,'ac','a',now());

鎖等待中……

Session2:

insert into t3 values(23,'bc','b',now());

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

當(dāng)對存在的行進(jìn)行鎖的時候(主鍵)峡蟋，mysql就只有行鎖坟桅。

當(dāng)對未存在的行進(jìn)行鎖的時候(即使條件為主鍵)，mysql是會鎖住一段范圍（有g(shù)ap鎖）

鎖住的范圍為：

(無窮小或小于表中鎖住id的最大值蕊蝗，無窮大或大于表中鎖住id的最小值)

如：如果表中目前有已有的id為（11 仅乓， 12）

那么就鎖住（12蓬戚，無窮大）

如果表中目前已有的id為（11 夸楣， 30）

那么就鎖住（11子漩，30）

對于這種死鎖的解決辦法是：

insert into t3(xx,xx) on duplicate key update `xx`='XX';

用mysql特有的語法來解決此問題豫喧。因?yàn)閕nsert語句對于主鍵來說，插入的行不管有沒有存在幢泼，都會只有行鎖

案例三

mysql> select * from t3 where id=9 for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
|  9 | JX     | f    | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+
 
row in set (0.00 sec)

Session2:

mysql> select * from t3 where id<20 for update;

鎖等待中

Session1:

mysql> insert into t3 values(7,'ae','a',now());

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

這個跟案例一其它是差不多的情況紧显，只是session1不按常理出牌了，

Session2在等待Session1的id=9的鎖缕棵，session2又持了1到8的鎖（注意9到19的范圍并沒有被session2鎖啄衩睢），最后挥吵，session1在插入新行時又得等待session2,故死鎖發(fā)生了重父。

這種一般是在業(yè)務(wù)需求中基本不會出現(xiàn)，因?yàn)槟沔i住了id=9忽匈，卻又想插入id=7的行房午，這就有點(diǎn)跳了，當(dāng)然肯定也有解決的方法丹允，那就是重理業(yè)務(wù)需求郭厌，避免這樣的寫法。

案例四

一般的情況雕蔽，兩個session分別通過一個sql持有一把鎖折柠，然后互相訪問對方加鎖的數(shù)據(jù)產(chǎn)生死鎖。

案例五

兩個單條的sql語句涉及到的加鎖數(shù)據(jù)相同批狐，但是加鎖順序不同扇售，導(dǎo)致了死鎖前塔。

案例六

死鎖場景如下：

表結(jié)構(gòu)：

CREATE TABLE dltask (
    id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT ‘a(chǎn)uto id’,
    a varchar(30) NOT NULL COMMENT ‘uniq.a’,
    b varchar(30) NOT NULL COMMENT ‘uniq.b’,
    c varchar(30) NOT NULL COMMENT ‘uniq.c’,
    x varchar(30) NOT NULL COMMENT ‘data’,   
    PRIMARY KEY (id),
    UNIQUE KEY uniq_a_b_c (a, b, c)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’deadlock test’;

a，b承冰，c三列华弓，組合成一個唯一索引，主鍵索引為id列困乒。

事務(wù)隔離級別：

RR (Repeatable Read)

每個事務(wù)只有一條SQL：

delete from dltask where a=? and b=? and c=?;

SQL的執(zhí)行計劃：

死鎖日志：

眾所周知寂屏，InnoDB上刪除一條記錄，并不是真正意義上的物理刪除娜搂，而是將記錄標(biāo)識為刪除狀態(tài)迁霎。

(注：這些標(biāo)識為刪除狀態(tài)的記錄，后續(xù)會由后臺的Purge操作進(jìn)行回收百宇，物理刪除考廉。但是，刪除狀態(tài)的記錄會在索引中存放一段時間恳谎。)

在RR隔離級別下芝此，唯一索引上滿足查詢條件憋肖，但是卻是刪除記錄因痛，如何加鎖？

InnoDB在此處的處理策略與前兩種策略均不相同岸更，或者說是前兩種策略的組合：對于滿足條件的刪除記錄鸵膏，InnoDB會在記錄上加next key lock X(對記錄本身加X鎖，同時鎖住記錄前的GAP怎炊，防止新的滿足條件的記錄插入谭企。)

Unique查詢，三種情況评肆，對應(yīng)三種加鎖策略债查，總結(jié)如下：

此處，我們看到了next key鎖瓜挽，是否很眼熟盹廷？

對了，前面死鎖中事務(wù)1久橙，事務(wù)2處于等待狀態(tài)的鎖俄占，均為next key鎖。

明白了這三個加鎖策略淆衷，其實(shí)構(gòu)造一定的并發(fā)場景缸榄，死鎖的原因已經(jīng)呼之欲出。

但是祝拯，還有一個前提策略需要介紹甚带，那就是InnoDB內(nèi)部采用的死鎖預(yù)防策略。

找到滿足條件的記錄，并且記錄有效欲低，則對記錄加X鎖辕宏，No Gap鎖(lock_mode X locks rec but not gap)；
找到滿足條件的記錄砾莱，但是記錄無效(標(biāo)識為刪除的記錄)瑞筐，則對記錄加next key鎖(同時鎖住記錄本身，以及記錄之前的Gap：lock_mode X);
未找到滿足條件的記錄腊瑟，則對第一個不滿足條件的記錄加Gap鎖聚假，保證沒有滿足條件的記錄插入(locks gap before rec)；

死鎖預(yù)防策略

InnoDB引擎內(nèi)部(或者說是所有的數(shù)據(jù)庫內(nèi)部)闰非，有多種鎖類型：事務(wù)鎖(行鎖膘格、表鎖)，Mutex(保護(hù)內(nèi)部的共享變量操作)财松、RWLock(又稱之為Latch瘪贱，保護(hù)內(nèi)部的頁面讀取與修改)。

InnoDB每個頁面為16K辆毡，讀取一個頁面時菜秦，需要對頁面加S鎖，更新一個頁面時舶掖，需要對頁面加上X鎖球昨。任何情況下，操作一個頁面眨攘，都會對頁面加鎖主慰，頁面鎖加上之后，頁面內(nèi)存儲的索引記錄才不會被并發(fā)修改鲫售。

因此共螺，為了修改一條記錄，InnoDB內(nèi)部如何處理：

根據(jù)給定的查詢條件情竹，找到對應(yīng)的記錄所在頁面藐不；
對頁面加上X鎖(RWLock)，然后在頁面內(nèi)尋找滿足條件的記錄鲤妥；
在持有頁面鎖的情況下佳吞，對滿足條件的記錄加事務(wù)鎖(行鎖：根據(jù)記錄是否滿足查詢條件，記錄是否已經(jīng)被刪除棉安，分別對應(yīng)于上面提到的3種加鎖策略之一)底扳；

相對于事務(wù)鎖，頁面鎖是一個短期持有的鎖贡耽，而事務(wù)鎖(行鎖衷模、表鎖)是長期持有的鎖鹊汛。因此，為了防止頁面鎖與事務(wù)鎖之間產(chǎn)生死鎖阱冶。InnoDB做了死鎖預(yù)防的策略：持有事務(wù)鎖(行鎖刁憋、表鎖)，可以等待獲取頁面鎖木蹬；但反之至耻，持有頁面鎖，不能等待持有事務(wù)鎖镊叁。

根據(jù)死鎖預(yù)防策略尘颓，在持有頁面鎖，加行鎖的時候晦譬，如果行鎖需要等待疤苹。則釋放頁面鎖，然后等待行鎖敛腌。此時卧土，行鎖獲取沒有任何鎖保護(hù)，因此加上行鎖之后像樊，記錄可能已經(jīng)被并發(fā)修改尤莺。因此，此時要重新加回頁面鎖凶硅，重新判斷記錄的狀態(tài)缝裁，重新在頁面鎖的保護(hù)下扫皱，對記錄加鎖足绅。如果此時記錄未被并發(fā)修改，那么第二次加鎖能夠很快完成韩脑，因?yàn)橐呀?jīng)持有了相同模式的鎖氢妈。但是，如果記錄已經(jīng)被并發(fā)修改段多，那么首量，就有可能導(dǎo)致本文前面提到的死鎖問題。

以上的InnoDB死鎖預(yù)防處理邏輯进苍，對應(yīng)的函數(shù)加缘，是row0sel.c::row_search_for_mysql()。感興趣的朋友觉啊，可以跟蹤調(diào)試下這個函數(shù)的處理流程拣宏，很復(fù)雜，但是集中了InnoDB的精髓杠人。

剖析死鎖的成因

做了這么多鋪墊勋乾，有了Delete操作的3種加鎖邏輯宋下、InnoDB的死鎖預(yù)防策略等準(zhǔn)備知識之后，再回過頭來分析本文最初提到的死鎖問題辑莫，就會手到拈來学歧，事半而功倍。

首先各吨，假設(shè)dltask中只有一條記錄：(1, ‘a(chǎn)’, ‘b’, ‘c’, ‘data’)枝笨。三個并發(fā)事務(wù)，同時執(zhí)行以下的這條SQL：

delete from dltask where a=’a’ and b=’b’ and c=’c’;

并且產(chǎn)生了以下的并發(fā)執(zhí)行邏輯揭蜒，就會產(chǎn)生死鎖：

上面分析的這個并發(fā)流程伺帘，完整展現(xiàn)了死鎖日志中的死鎖產(chǎn)生的原因。其實(shí)忌锯，根據(jù)事務(wù)1步驟6伪嫁，與事務(wù)0步驟3/4之間的順序不同，死鎖日志中還有可能產(chǎn)生另外一種情況偶垮，那就是事務(wù)1等待的鎖模式為記錄上的X鎖 + No Gap鎖(lock_mode X locks rec but not gap waiting)张咳。這第二種情況，也是”潤潔”同學(xué)給出的死鎖用例中似舵，使用MySQL 5.6.15版本測試出來的死鎖產(chǎn)生的原因脚猾。

此類死鎖，產(chǎn)生的幾個前提：

Delete操作砚哗，針對的是唯一索引上的等值查詢的刪除龙助；(范圍下的刪除，也會產(chǎn)生死鎖蛛芥，但是死鎖的場景提鸟，跟本文分析的場景，有所不同)
至少有3個(或以上)的并發(fā)刪除操作仅淑；
并發(fā)刪除操作称勋，有可能刪除到同一條記錄，并且保證刪除的記錄一定存在涯竟；
事務(wù)的隔離級別設(shè)置為Repeatable Read赡鲜，同時未設(shè)置innodb_locks_unsafe_for_binlog參數(shù)(此參數(shù)默認(rèn)為FALSE)；(Read Committed隔離級別庐船，由于不會加Gap鎖银酬，不會有next key，因此也不會產(chǎn)生死鎖)
使用的是InnoDB存儲引擎筐钟；

MySQL學(xué)習(xí)筆記-死鎖產(chǎn)生原因和解決方法

MySQL學(xué)習(xí)筆記-死鎖產(chǎn)生原因和解決方法

Mysql 鎖類型

一头遭、鎖類型介紹：

二懈费、死鎖產(chǎn)生原因和示例

1、產(chǎn)生原因：

2、產(chǎn)生示例：

案例一

案例二

案例三

案例四

案例五

案例六

死鎖預(yù)防策略

剖析死鎖的成因