关于for update和lock in share mode的区别及说明
作者:小淼同学
lock in share mode 就是共享锁
如果事务对某行数据加上共享锁之后,可进行读写操作;其他事务可以对该数据加共享锁,但不能加排他锁,且只能读数据,不能修改数据。
某个事物想进行修改数据操作,那他必须等其他事物的共享锁都释放完毕才能进行修改操作
for update 排他锁,就是行锁
如果事务对数据加上排他锁之后,则其他事务不能对该数据加任何的锁。
获取排他锁的事务既能读取数据,也能修改数据。
注:普通 select 语句默认不加锁,而CUD操作默认加排他锁。
例子
下面例子的前提都是针对同一行数据。
1.同一行数据为前提,两个事物都进行共享锁查询
2.同一行数据为前提,一个事物进行共享锁查询,另一个事物进行修改
第一个占有着共享锁,第二个事物没法更新,必须等第一个事物释放才能进行更新
3.同一行数据为前提,一个进行共享锁查询,另一个先进行共享锁查询,然后update
同第二种,修改的事物就一直在转圈圈,等待事物1提交。事物1不提交,那事物2只能等到超时返回错误。
4.同一行数据为前提,当事物一获得共享锁,另一个事物是否可以获得排它锁
答案是不能,事物二就一直转圈圈,等待1的释放
结论:同一行数据为前提,当一个事物获得共享锁,另一个事物可以获得共享锁进行读操作,但不能进行修改操作,想要修改必须等其他的共享锁释放完毕。还有一个事物获得了共享锁,另一个事物不能获得排它锁
5.同一行数据为前提,一个事物获取到排他锁,另一个事物进行查询
结果是可以的,一个获取排它锁,另一个进行普通查询
6.同一行数据为前提,一个事物获取到排他锁,另一个事物进行共享锁的获取
结果如图2,爱的魔力转圈圈,就一直卡在那里
7.同一行数据为前提,一个事物获取排它锁,另一个事物是否可以进行修改
结果如图2,爱的魔力转圈圈,就一直卡在那里
8.同一行数据为前提,一个事物获取排它锁,另一个是否可以获取排它锁
结果如图2,爱的魔力转圈圈,就一直卡在那里
结论:当前事务获取某行数据排他锁后,其他事务是否可以对该行数据进行读写操作和获取共享锁:其他事务可以读,不可以获取共享锁,不可以写
这里再给读者科普一点,行锁和索引的关系:查询字段未加索引(主键索引、普通索引等)时,使用表锁
注:InnoDB行级锁基于索引实现。
未加索引时,两种行锁情况为(使用表锁):
- 事务1获取某行数据共享锁,其他事务可以获取不同行数据的共享锁,不可以获取不同行数据的排他锁
- 事务1获取某行数据排他锁,其他事务不可以获取不同行数据的共享锁、排他锁
加索引后,两种行锁为(使用行锁):
- 事务1获取某行数据共享锁,其他事务可以获取不同行数据的排他锁
- 事务1获取某行数据排他锁,其他事务可以获取不同行数据的共享锁、排他锁
表结果:
CREATE TABLE `pf_banner` ( `id` bigint(22) NOT NULL AUTO_INCREMENT, `num` int(11) DEFAULT NULL, `title` varchar(80) DEFAULT NULL, `url` varchar(255) DEFAULT NULL, `img` varchar(255) DEFAULT NULL, `status` tinyint(4) DEFAULT '1' COMMENT '状态 1:显示 -1不显示', `create_time` datetime DEFAULT NULL, `modify_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='banner位图片'
例子
1.未加索引,事务1获取某行数据共享锁,事务2更新不同行数据阻塞:
2.未加索引,事务1获取某行数据共享锁,事务2获取不同行数据共享锁成功:
3.未加索引,事务1获取某行数据排他锁,事务2获取不同行数据共享锁阻塞:
4.未加索引,事务1获取某行数据排他锁,事务2获取不同行数据排他锁阻塞:
加索引后表结构:
CREATE TABLE `pf_banner` ( `id` bigint(22) NOT NULL AUTO_INCREMENT, `num` int(11) DEFAULT NULL, `title` varchar(80) DEFAULT NULL, `url` varchar(255) DEFAULT NULL, `img` varchar(255) DEFAULT NULL, `status` tinyint(4) DEFAULT '1' COMMENT '状态 1:显示 -1不显示', `create_time` datetime DEFAULT NULL, `modify_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_num` (`num`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='banner位图片'
1.加索引后,事务1获取某行数据共享锁,事务2可以更新不同行数据:
2.加索引后,事务1获取某行数据共享锁,事务2获取不同行数据共享锁成功:
3.加索引后,事务1获取某行数据排他锁,事务2获取不同行数据排他锁成功:
4.加索引后,事务1获取某行数据排他锁,事务2获取不同行数据共享锁成功:
科普小知识2:索引数据重复率太高会导致全表扫描:当表中索引字段数据重复率太高,则MySQL可能会忽略索引,进行全表扫描,此时使用表锁。可使用 force index 强制使用索引。
操作步骤
1.事务1,执行鼠标选中的内容
2.事物2,执行鼠标选中的内容
你会发现事物2会一直转圈圈,其实在执行update的时候,已经是表锁了。导致事物2 进行行锁的时候,需要等待事物1的释放
现在,我们使用强制锁进行更新操作。
当你使用强制索引的时候,就会发现更新成功了。
当然数据重复降低,也是能成功的
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。