MySQL-锁 个人理解

行锁

对数据库表行记录进行加锁。
比如:id为 table1 表主键
当 id=1 数据 存在 的情况下,SQL语句:
update table1 set field1=param1 where id=1;
(
或 delete from table1 where id=1;
或 select * from table1 where id=1 for update;
)
实则是当前事务(事务T)对 id=1的这行数据 加的 行锁,直到事务提交或回滚,锁释放。

写锁、排他锁(X锁)

如上例子,实则也是对id=1的这行数据加的是一个写锁,它是一个排他锁。
排他锁(X锁):
若 事务T 对 数据a 加上X锁 ,事务T 就具备了 数据a 的读写权限,其它事务不能再对 数据a 加任何锁,直到 事务T 释放 数据a 上的锁。

行锁 一定是 排他锁吗?

不一定!
行锁字面意思 就是 对 行进行加锁,只要对行进行加锁都可以叫行锁。但是从另一个层面讲,对这 行数据 进行加锁不是非得加 排他锁,也可以对行数据加 共享锁;如下
SELECT * FROM table1 WHERE id=1 LOCK IN SHARE MODE;
在 id =1 数据存在的情况下 ,这里实则是对 id=1的数据行加的 共享锁LOCK IN SHARE MODE

读锁、共享锁(S锁)

如:

SELECT * FROM table1 WHERE id=1 LOCK IN SHARE MODE;

若事务T对数据对象A加上S锁,在事务T未释放数据A的S锁之前,其它事务也可以对数据对象A加S锁,针对数据A上的这把锁是共享的,所以叫 共享锁

但是 在两个事务都持有了数据A的S锁之后,事务1未结束前是不允许事务2 针对 锁定的数据 做 具体写操作的,同样,事务2在未结束前也不允许事务1 对锁定的数据做 写操作。

如果 事务1 事务2 持有了同一把 共享锁,如果这时 事务1 对锁定的数据 做写操作,那么会被阻塞。如果事务2 在事务1被阻塞的情况下 也执行写操作,那么会出现死锁问题。

其它情况下的共享锁:
当主键id=1的数据不存在时,MySQL RR(默认事务隔离级别——可重复读) 隔离级别下,如下:
select * from table1 where id = 1 for update;

update table1 set filed1=param1 where id = 1;

INSERT INTO table1
SELECT 1,'Tom','male','19' FROM DUAL
WHERE NOT EXISTS (SELECT *FROM table1 where id = 1);
如上三条SQL语句,实则也是 对 id=1 所处的 主键间隙空间 加的 共享锁,这里 也是 一个 间隙锁。(RC不存在间隙锁)

图解 S锁与X锁 兼容、互斥关系


image.png

间隙锁(Gap Lock)

条件:RR事务隔离级别下
锁加在不存在的空闲空间,可以是两个索引记录之间,也可能是第一个索引记录之前或最后一个索引之后的空间。
间隙锁是封锁索引记录中的间隔,或者第一条索引记录之前的范围,又或者最后一条索引记录之后的范围。

下图就是六条记录,并且形成了7个间隙。 那么对间隙上锁,就是间隙锁。


image.png

间隙锁可能出现的问题演示
演示1:

image.png

image.png

如上图,如果事务1 步骤5 插入的是 id= 98 ,事务2 步骤6 插入的是 id=99 数据,那么 不会出现 阻塞 死锁问题。

演示2:


image.png

表锁

对整个表进行上锁的操作,叫表锁
对表进行加锁
LOCK TABLES table_name WRITE/READ;
解锁 (释放当前会话所加的表锁)
UNLOCK TABLES;

如上方式对表进行加锁,是一种绝对加锁的方式。

如果 对表 加了写锁 以后,其它 会话,无法读表中任何数据(普通select也不行),无法做任何修改,只能阻塞,直到 表锁 释放;

如果 对表 加了读锁 以后,其它会话可以 继续读取数据,或者继续对表加读锁(共享锁),但是在加了读锁之后,其它会话就不能去修改表中任何数据,直到锁释放;

如下 操作,也会 对 表整个范围进行加锁(不同种类锁,范围覆盖整个表,也叫表锁)。

在RR的隔离级别下,当color字段 为 非索引字段时:
update table_name set field1=param1 where color='red';
全表扫描,最终导致 上锁的范围为整个表,其中有 X锁 有 Gap锁。


image.png

从锁定范围来讲,这里也叫表锁;

插入意向锁(InnoDB)

多个事务,在同一个索引,同一个范围区间插入记录时,如果插入的位置不冲突,不会阻塞彼此。

在插入数据时,会产生插入意向锁,会对意向id位置进行上锁(非Gap锁),属于排他锁;

事务1 插入id为1的数据,挂起事务不提交,事务2 也插入id为1的数据,则需要阻塞,直到事务1释放 意向锁。事务2 两种结果:1、主键冲突,2、执行成功;

如果事务1 插入id为1数据,事务2插入id为2数据,则互不影响。

如上内容,如有 疑问,欢迎沟通指正。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容