计算机程序锁
- 控制对共享资源进行并发访问
- 保护数据的完整性和一致性
![](https://i-blog.csdnimg.cn/blog_migrate/d659e1b2b44ac8b99418a6883346e32a.png)
lock 主要是事务,数据库逻辑内容,事务过程
latch/mutex 内存底层锁;
更新丢失
原因:
B的更改还没有提交时,A已经再次修改了数据。
此时A使用原来的元数据作为基础更新后,B的更新便会丢失;
![](https://i-blog.csdnimg.cn/blog_migrate/d4450a5760d77cbeca180739a5726015.png)
解决办法:
在修改数据上加写锁,当有锁时,A会等B更新提交完,才可以继续在B的基础上继续更新;
![](https://i-blog.csdnimg.cn/blog_migrate/a54f83196e30a9af791e21ef8798c4aa.png)
事务锁粒度
行锁: innodb ,oracle
页锁:sql server
表锁:Myisam ,memory
获取innodb行锁争用情况
mysql> show status like '%innodb_row_lock%'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Innodb_row_lock_current_waits | 0 | | Innodb_row_lock_time | 0 | | Innodb_row_lock_time_avg | 0 | | Innodb_row_lock_time_max | 0 | | Innodb_row_lock_waits | 0 | +-------------------------------+-------+ 5 rows in set (0.00 sec)
如果发现锁争用比较严重,如innodb_row_lock_waits 和 innodb_row_lock_time_avg的值比较高,
还可以通过设置innodb monitor 来进一步观察发生锁冲突的表,数据行等,并分析锁争用的原因:
innodb锁模式与粒度
四种基本锁模式
- 共享锁(S)-读锁-行锁
- 排他锁(X)-写锁-行锁
- 意向共享锁(IS)-表级 :事务想要获得一张表中某几行的共享锁
- 意向排他锁(IX)-表级:事务想要获得一张表中某几行的排他锁
意向锁,简单来说就是:
如需要对页上的记录R进行X锁,那么分别需要对该记录所在的数据库,表,页,上意向锁IX,最后对记录R上X锁。
若其中任何一个部分导致等待,那么该操作需要等待粗粒度锁的完成。
innodb支持意向锁设计比较简练,其意向锁即为表级别的锁。设计目的主要是为了在一个事务中揭示下一行将被请求的锁类型。
意向锁:
- 意向锁总是自动先加,并且意向锁自动加自动释放
- 意向锁提示数据库这个session将要在接下来将要施加何种锁
- 意向锁和X/S 锁级别不同,除了阻塞全表级别的X/S锁外其他任何锁
自动施加,自动释放,
innodb锁模式互斥
![](https://i-blog.csdnimg.cn/blog_migrate/7e1c3865ea1a42462047e00df86e1277.png)
数据库加锁操作
一般的select语句不加任何锁,也不会被任何事物锁阻塞
读的隔离性由MVCC确保
undo log 用来帮助事务回滚及MVCC(多版本并发控制 ,即select时可以使用行数据的快照,而不用等待锁资源)
S锁
手动:select * from tb_test lock in share mode;
自动:insert前
X锁
手动:
select * from tb_test for update;
自动:update,delete 前
线上环境中:
![](https://i-blog.csdnimg.cn/blog_migrate/a44e7cde076b072630c5e892c22843fa.png)
锁等待时间:innodb_lock_wait_timeout
mysql>show global variables like "%wait%"
innodb 行锁
通过索引项加锁实现
- 只有条件走索引才能实现行级锁 a)
- 索引上有重复值,可能锁住多个记录 b)
- 查询有多个索引可以走,可以对不同索引加锁 c)
- 是否对索引加锁实际上取决于Mysql执行计划
自增主键做条件更新,性能做好;
通过索引项加锁实现的例子:
a) 只有,有条件走索引才能实现行级锁
mysql> show create table t2\G; *************************** 1. row *************************** Table: t2 Create Table: CREATE TABLE `t2` ( `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 mysql> select * from t2; +------+------+ | a | b | +------+------+ | 1 | 2 | | 1 | 3 | +------+------+ 此时A连接 在b =2 时加 写锁; mysql> select * from t2 where b =2 for update; +------+------+ | a | b | +------+------+ | 1 | 2 | +------+------+ 而此时再B连接中再对b=3,加写锁时,失败; mysql> select * from t2 where b=3 for update; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
说明,表中没有索引时,innodb将对整个表加锁,而不能体现行锁的特性;
b) 索引上有重复值,可能锁住多个记录
mysql> show create table t2\G; *************************** 1. row *************************** Table: t2 Create Table: CREATE TABLE `t2` ( `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, KEY `a` (`a`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 1 row in set (0.00 sec) mysql> select * from t2; +------+------+ | a | b | +------+------+ | 1 | 2 | | 1 | 3 | | 2 | 9 | +------+------+ 在A连接中,在a=1,b=2处加一个写锁;实际上 是在a=1这个索引上加的锁 mysql> select * from t2 where a=1 and b=2 for update; +------+------+ | a | b | +------+------+ | 1 | 2 | +------+------+ 1 row in set (0.00 sec) 在B连接中,在a=1 and b=3处加写锁失败,因都是a=1这个索引,而A中已经对a=1这个索引的行加过了锁; mysql> select * from t2 where a =1 and b=3 for update; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 此时B连接是可以对 a=2 and b =9 这一行中,在a=2 这个索引上加锁的; mysql> select * from t2 where a=2 and b =9 for update ; +------+------+ | a | b | +------+------+ | 2 | 9 | +------+------+
注意
行锁升级成表锁:
mysql> select * from t2 where b =9 for update ;
这句对本意在b=9这行加索引,b又没有加索引,所以这是对整个表加锁;因为没有指定a =2,所以mysql找不到a这个索引的;
c) 查询有多个索引可以走,可以对不同索引加锁
mysql> show create table t2\G; *************************** 1. row *************************** Table: t2 Create Table: CREATE TABLE `t2` ( `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, KEY `a` (`a`), KEY `b` (`b`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 mysql> select * from t2; +------+------+ | a | b | +------+------+ | 1 | 2 | | 1 | 3 | | 2 | 9 | +------+------+ 在A连接中对 a=1 and b=2 加锁; mysql> select * from t2 where a =1 and b =2 for update; +------+------+ | a | b | +------+------+ | 1 | 2 | +------+------+ 此时B连接中对a =1 and b=3 ,也是可以加锁的;这是因为mysql 可以从a=1这个索引来加锁,也可以对b=3加锁; 所以就与上面b)中只能对a=1索引来加锁 区别开来; mysql> select * from t2 where a =1 and b =3 for update; +------+------+ | a | b | +------+------+ | 1 | 3 | +------+------+
innodb的gap lock 间隙锁
gap lock消灭幻读
innodb消灭幻读仅仅为了确保 statement模式
replicate的主从一致性
小心gap lock
自增主键做条件更新,性能最好;
gap lock 间隙锁 解释:
mysql> select * from t2; +------+------+ | a | b | +------+------+ | 20 | 2 | | 24 | 4 | | 27 | 5 | | 27 | 6 | | 27 | 8 | | 30 | 6 | | 31 | 4 | | 32 | 9 | +------+------+ 8 rows in set (0.00 sec) 在A连接中给a=27 加锁(a 是有索引的) mysql> select * from t2 where a=27 for update; +------+------+ | a | b | +------+------+ | 27 | 5 | | 27 | 6 | | 27 | 8 | +------+------+ 3 rows in set (0.00 sec)
此时隔离等级是Repeatable Read,标准的是可以出现幻读现象的,
即在B连接中 insert into t2 values(27,3),是可以插入成功的,而且B连接提交后,A连接是可以查看到增加的,27,3这一行的。
而innodb 通过间隙锁是的B连接中 insert into t2 values(27,3) 插入失败,来消灭幻读的出现。
但是这种方法是有
局限的,它会将
a=24--29(30-1)中间的任何数都锁住,所以才叫间隙锁;
B连接中则只能插入不在这个区间的数据;
锁升级
- 由一句单独的sql语句在一个对象上持有的锁的数量超过了阈值,默认这个阈值为5000.值得注意的是,如果是不同对象,则不会发生锁升级。
- 锁资源占用的内存超过了激活内存的40%时就会发生锁升级
innodb不存在锁升级的问题。因为其不是根据每个记录来产生行锁的,相反,其根据每个事务访问的每个页对锁进行管理的,采用的是
位图的方式。因此不管一个事务锁住页中一个记录还是多个记录,其开销通常都是一致的。
简单说innodb根据页进行加锁,并采用位图方式,定位到行的,所需资源较小。
例子:
![](https://i-blog.csdnimg.cn/blog_migrate/4503e00f8164cc58a34286dbcb2bfd0c.png)
死锁
![](https://i-blog.csdnimg.cn/blog_migrate/c0acc170b15b3c380f4152829b166ed7.png)
死锁数据库自动解决
数据库挑选冲突事务中回滚代价较小的事务回滚
死锁预防
单表死锁可以根据批量更新表的更新条件排序
可能冲突的跨表事务尽量避免并发
尽量缩短事务长度
排查死锁:
- 了解触发死锁的sql所在事务的上下文
- 根据上下文语句加锁的范围来分析存在争用的记录
- 通常改善死锁的主要方法:
--对同一表的操作根据加锁条件进行排序
--拆分长事务
业务逻辑加锁
业务流程中的悲观锁(开始的时候,在所有记录加锁,直到最后释放;而乐观锁开始不加锁,只是在最后提交中看提交有没有成功,没成功返回给应用程序)
悲观锁开始就给所有记录加锁,一般等所有业务流程完成,才释放锁;因此会对并发性能有一定的影响;
如何缩短锁的时间?
1)开始的时候读取要修改的数据,amount(金额)
2)做业务流程
3)在update时,加锁且判断,现在的amount和开始的amount是否为一个值,如果是,说明这期间amount为改变,则更新;如果amount值改了,则不更新,交给业务来判断该怎么做。
这样仅是在update这个语句加锁,大大的缩短的锁的时间提高了并发性;
但是如果业务十分的繁忙,amount的值在不断改变,此时这个update 就不断的失败,整个事务就不断的失败,反而影响了 性能。那么该如何做呢?
在开始的时候不读取数据,等到要提交的时候读取并加锁提交;
总结
- 更新丢失
- innodb意向锁:
-
- 表锁
- 自动施加、自动释放
- 为了揭示事务下一行将被请求的锁类型
- S锁:in share mode
- X锁:for update
- innodb行锁特点:
-
- 只有条件走索引才能实现行锁
- 索引上有重复值可能锁住多个记录
- 查询有多个索引可以走,可以对不同索引加锁
- gap lock:间隙锁,消灭幻读
- 死锁解决:数据库挑回滚代价较小的事务回滚;
- 死锁预防:
-
- 单表,更新条件排序
- 避免跨表事务,缩短事务长度
- 锁升级:
-
- 单独sql语句在单个对象的锁数量超过阙值
- 锁资源占用的内存超过了激活内存的40%;
- innodb根据页进行加锁,并采用位图方式,定位到行的,所需资源较小