innodb 表锁和行锁
表锁相关结构:
table->locks:数据字典table保存这个表上的所有表锁信息
trx->lock.table_locks:每个事务trx保存该事务所加的所有表锁信息
trx->lock.trx_locks:每个事务trx保存该事务所有的锁信息(包括行锁)
表锁类型:
IS IX S X AI
AI:Auto-Increment Lock 也是表级的,语句结束后释放而不事事务结束后释放
http://dev.mysql.com/doc/refman/5.5/en/innodb-auto-increment-handling.html
lock_table 加锁流程
1 先从 trx->lock.table_locks 查找该事务是否已加对该表加锁,如果所加的锁比要加的锁strong,则返回成功。其它情况进入2
2 从 table->locks中查找该表是否被其他事务加锁。如果没有加锁进入3,如果已加锁进入4
3 新建表锁,返回加锁成功
4 此时需判断欲加的锁是否与已加的锁兼容。如果兼容进入5,否则进入6
5 新建表锁,返回加锁成功
6 新建表锁,加入等待队列,其中会穿插死锁检测流程。
新建表锁会将新建的锁放入table->locks,trx->lock.table_locks,trx->lock.trx_locks中。
?
附锁兼容矩阵和锁
/* LOCK
COMPATIBILITY MATRIX
*
IS IX S X AI
*
IS + + + - +
*
IX + + - - +
*
S + - + - -
*
X - - - - -
*
AI + + - - -
锁强度比较矩阵
/* STRONGER-OR-EQUAL RELATION (mode1=row, mode2=column)
* IS IX S
X AI
*
IS + - - - -
*
IX + + - - -
*
S + - + - -
*
X + + + + +
*
AI - - - - +
*
See lock_mode_stronger_or_eq().
*/
记录锁
记录锁的存储单位为页,一个事务在一个页上的所有同类型锁存储为一个lock,lock中通过bitmap来表示那些记录已加锁
行锁类型:行锁类型由基本类型和精确类型组成
行锁基本类型:
LOCK_S,LOCK_X
行锁精确类型:
LOCK_ORDINARY(NK):next-key lock 既锁记录也锁记录前的gap
LOCK_GAP(GAP):不锁记录,只锁记录前的gap
LOCK_REC_NOT_GAP(NG):只锁记录,不锁记录前的gap
LOCK_INSERT_INTENTION(I):insert时,若insert位置已有gap锁,则需加LOCK_INSERT_INTENTION锁
相关结构:
trx->lock.trx_locks:每个事务trx保存该事务所有的锁信息(表锁和行锁)
lock_sys->rec_hash:保存所有事务的行锁信息
给记录加S锁之前必会给表加IS锁
给记录加X锁之前必会给表加IX锁
lock_rec_lock流程
分为两个阶段快加锁和慢加锁阶段,设记录所在的页为p
1 快加锁阶段:
1.1 在 lock_sys->rec_hash中查找P的所有锁,如果没有锁,则新建锁返回成功;否则进入1.2
1.2 如果查找到只有一个锁,且该所在的事务是当前事务,锁类型也相同,则进入1.3,否则,进入第二阶段快加锁阶段
1.3 如将该记录已加锁,则返回加锁成功。否则进入1.4
1.4 将该记录在lock的bitmap的位置为已加锁。返回成功。
2 慢加锁阶段
2.1 在lock_sys->rec_hash中遍历查找当前事务对此记录所加的锁,如果已有锁比欲加的锁strong(见lock_rec_has_expl),则进入2.2,否则进入2.3。
2.2. 如果已有锁状态为wait,则当前事务进入等待。否则直接返回加锁成功。
2.3 在lock_sys->rec_hash中遍历查找对此记录所加的锁 ,如果所在的事务是其他事务且锁不兼容则进入等待,否则进入2.4
2.4 如是隐式加锁,则返回成功,否则进入2.5
2.5 如果当前记录已有锁等待(?),或当前事务没有同类型的锁设置bitmap位,则新建锁返回成功(见lock_rec_add_to_queue) ,否则进入2.6
2.6 在当前事务同类型的锁上设置bitmap位,返回成功
可见慢加锁阶段可能会两次遍历lock_sys->rec_hash的哈希桶。
行锁的兼容和锁比较没有表锁那么简单,是由于引入行锁精确类型导致的。
兼容性有以下原则
1 Gap type locks without LOCK_INSERT_INTENTION flag do not need to wait for anything. This is because different users can have conflicting lock types on gaps
2 Record lock (LOCK_ORDINARY or LOCK_REC_NOT_GAP does not need to wait for a gap type lock
3 Lock on gap does not need to wait for a LOCK_REC_NOT_GAP type lock
4 No lock request needs to wait for an insertintention lock to be removed.
可以推出以下锁兼容矩阵
GAP I NG NK
GAP + + + +
I +
NG + +
NK + +
对于锁强度比较可以参考lock_rec_has_expl,对于SUPREMUM记录的处理比较特殊。
锁强度矩阵(strong or equ)
GAP I NG NK
GAP - -
I -
NG - -
NK -
而对于SUPREMUM记录NG和G是+。
关于 lock的bitmap,当记录发生移动和page发生分裂和合并时都需要维护bitmap信息,参见lock_rec_move lock_update_merge_right
死锁检测
死锁检测发生在锁等待时,参见lock_deadlock_check_and_resolve。表锁和记录锁的检测逻辑是一样的。
采用等待图法,事务是图的节点,事务与该事务所等待的锁所在的事务的连线构成线,如果发现图中存在回路,则表示系统中出现了死锁。innodb采用图的深度优先的非递归算法实现的。非递归采用栈来记录节点的访问轨迹。lock->trx->lock.deadlock_mark和 ctx->mark_start来判断节点是否已访问过。
死锁检测有三种结果:
1 检查过程中搜索节点过深(>200)或访问的节点数过多(>1000000),或栈节点数超过srv_max_n_threads(?),则停止搜索,实际上就是认为产生了死锁。而不是采用超时的方法。此时将欲加的锁的事务做为牺牲者。
2 检测到死锁,这是需要选择牺牲者。在当前事务和等待的锁事务中选择,原则是牺牲undo和持有锁较少的事务。(trx_weight_ge)
作为牺牲者的事务会回滚,从而释放锁持有的锁,从而断开了环路,解决了死锁。
锁的释放
事务提交和回滚是会释放锁
另为自增锁在语句结束时释放lock_unlock_table_autoinc
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。