阅读mysql wait-for graph相关文档
This commit is contained in:
@@ -313,6 +313,32 @@ update语句获取锁的情况如下:
|
||||
||TABLE|IX|GRANTED||
|
||||
|PRIMARY|RECORD|X,REC_NOT_GAP|GRANTED|3|
|
||||
|
||||
### innodb死锁
|
||||
当innodb中多个事务持有各自的资源并同时请求对方所持有的资源时,就会发生死锁。当发生死锁时,事务获取锁的请求会被阻塞,阻塞超时后,会根据诗剧苦设置决定是否回滚(`innodb_rollback_on_timeout`)。
|
||||
|
||||
#### 超时
|
||||
在innodb中,可以通过如下变量来控制innodb的超时时间和超时后行为
|
||||
- innodb_lock_wait_timeout: 超时等待时间,默认为`50`,即超时时间限制为50s
|
||||
- innodb_rollback_on_timeout: 在等待超时后,对事务是否进行回滚,默认为`OFF`,代表不回滚
|
||||
|
||||
#### wait-for graph
|
||||
相较于被动等待持有锁的事务超时,wait-for graph是一种更加主动的死锁检测方式。
|
||||
|
||||
在wait-for graph中,`节点`代表`事务`,而节点指向另一个节点的有向边则代表事务事务之间的等待关系。
|
||||
|
||||
wait-for graph中,事务`t1`指向事务`t2`的有向边代表如下两种可能的场景:
|
||||
- 事务t1所等待的资源正在被事务t2占用
|
||||
- 事务t1和事务t2都在等待相同的资源,但是在等待队列中,t2的排序在t1的前面,只有t2获取等待的资源并释放后,t1才能获取
|
||||
|
||||
故而,`在wait-for grah中存在回路时,则代表当前存在死锁。`
|
||||
|
||||
### innodb锁升级
|
||||
在其他数据库中,可能会将多个细粒度锁合并为一个粗粒度锁,从而减少锁占用的资源,例如将1000个行锁合并为一个页锁。
|
||||
|
||||
但是,`innodb`中并不存在锁升级问题。innodb中,锁是按页进行管理的,通过位图(bitmap)来对锁进行管理,页中不论有多少条记录进行了加锁,锁占用的资源都是相同的。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user