码迷,mamicode.com
首页 > 数据库 > 详细

innodB的隐式锁

时间:2016-07-21 12:25:58      阅读:519      评论:0      收藏:0      [点我收藏+]

标签:

http://blog.csdn.net/taozhi20084525/article/details/19545231

一、知识准备之隐式锁

 

参考:http://www.uml.org.cn/sjjm/201205302.asp

Innodb 实现了一个延迟加锁的机制,来减少加锁的数量,在代码中称为隐式锁(Implicit Lock)。隐式锁中有个重要的元素,事务ID(trx_id)。隐式锁的逻辑过程如下:

A. InnoDB的每条记录中都一个隐含的trx_id字段,这个字段存在于簇索引的B+Tree中。

B. 在操作一条记录前,首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务,首先将隐式锁转换为显式锁(就是为该事务添加一个锁)。

C. 检查是否有锁冲突,如果有冲突,创建锁,并设置为waiting状态。如果没有冲突不加锁,跳到E。

D. 等待加锁成功,被唤醒,或者超时。

E. 写数据,并将自己的trx_id写入trx_id字段。Page Lock可以保证操作的正确性。

 

二、具体代码

转自:《InnoDB SMO & Page Extent & Lock & Latch》 by 何登成

InnoDB 的 insert 操作,对插入的记录不加锁,但是此时如果另一个线程进行当前读,类似与以下的用例,session 2 会锁等待 session 1,那么这是如何实现的呢?

 

session 1:                			session 2:
set autocommit = ‘ off ’;
insert into c values (11, ’ aaa’);
					        select * from c where c1 = 11 lock in share mode;

 

下面是 session 2 的源码跟踪流程:

 

row_search_for_mysql();
sel_set_rec_lock();
…
	//  将记录上的 implicit 锁转换为 explicit 锁
	lock_rec_convert_impl_to_expl();
		//  查询当前记录上是否存在 implicit 锁
		// 1.  必须已经持有了 kernel mutex
		// 2.  获取记录上的 DB_TRX_ID 系统列,获取事务 ID
		// 3.  根据事务 ID,判断当前事务是否为活跃事务
		// 4.  若为活跃事务,则返回此活跃事务对象
		impl_trx = lock_clust_rec_some_has_impl(rec, index, offsets);
			ut_ad(mutex_own(&kernel_mutex));
			trx_id = row_get_rec_trx_id();
			trx_is_active(trx_id);
		//  判断返回事务,是否含有 explicit 锁;若有,直接返回;否则将
		// implicit 锁转化为 explicit 锁;由 session 2 完成 session 1 insert 记录的加锁
		lock_rec_has_expl(impl_trx);
		//  当前 session 1 不存在 explicit 锁,因此直接创建一个锁,锁模式为
		// LOCK_REC | LOCK_X | LOCK_REC_NOT_GAP
		//  由于 insert 记录上不可能有其他锁,因此转化直接成功,X 锁加上
		lock_rec_add_to_queue();
//  完成 session 1  的 insert 操作的 implicit 到 explicit 锁转化之后,此时可以加 session 2
//  的 scan S 锁,但是会等待 session 1 放锁
lock_rec_lock();

备注:Insert 不加锁,或者说是 Implicit Lock 的意义其实十分重大。从前面介绍的 Lock 结构中,我们可以分析出,其实 InnoDB 的一个锁结构的开销是比较大的。 或者说InnoDB 锁一条记录的开销,与锁一个页面中所有记录的开销是一样的。而 Insert 通过 Implicit 方式加锁,极大的减轻了 Insert 时的锁模块开销,对于 InnoDB 支持并发 Insert 操作,是一个极大的提升。

 

三、隐式锁的重要问题——check Duplicate

转自:《InnoDB SMO & Page Extent & Lock & Latch》 by 何登成

进一步参考: Innodb锁系统 Insert/Delete 锁处理及死锁示例分析 http://fan0321.iteye.com/blog/1984364

这里主要看聚集索引的check duplicate。check duplicate也就是保证在隐式锁情况下,多个事务的insert是如何保证索引的unique的。

1、聚集索引check duplicate

 

ha_innobase::write_row();
	…
	row_ins_index_entry_low();
		//  做 search path,将 cursor 定位到第一个小于等于插入值的位置
		btr_cur_search_to_nth_level(PAGE_CUR_LE);
		// cursor 是 binary search 之后在叶节点定位的 insert 位置
		//  判断 binary search 的结果,当前记录与待 insert 记录有几个相同的列
		//  若相同列取值的列数量(cursor->low_match),超过当前索引的唯一键值数量,
		//  则可能存在唯一性键值冲突
		row_ins_duplicate_error_in_clust(cursor, entry, thr);
			n_unique = dict_index_get_n_uniques();
			if (cursor->low_match >= n_unique)
				//  对 cursor 对应的已有记录加 S 锁(可能会等待),保证记录上的操作,包括:
				// Insert/Update/Delete 已经提交或者回滚
				// S 锁已经可以保证其他事务的 insert 操作不能进行,因为在真正
				// insert 操作进行时,会尝试对 下一个record加 X 锁,详见下一章节分析
				row_ins_set_shared_rec_loc(LOCK_S);
					lock_clust_rec_read_check_and_lock();
						//  判断 cursor 对应的记录上是否存在 implicit 锁(有活跃事务)
						//  若存在,则将 implicit 锁转化为 explicit 锁
						lock_rec_convert_impl_to_expl();
						lock_rec_lock();  //如果上面的隐式锁转化成功,此处加S锁将会等待,直到活跃事务释放锁。
				// S 锁加锁完成之后,可以再次做判断,最终决定是否存在 unique 冲突
				// 1.  判断 insert 记录与 cursor 对应的记录取值是否相同
				// 2.  二级唯一键值锁引,可以存在多个 NULL 值
				// 3.  最后判断记录的 delete_bit 状态,判断记录是否被删除提交
				row_ins_dupl_err_with_rec();
					cmp_dtuple_rec_with_match();
					return !rec_get_deleted_flag();

 

注意:S锁加锁成功之时,活跃事务应当提交或回滚并释放锁;但不管是提交还是回滚,cursor指向的record仍然存在,可能会有delete标志(发生回滚)。

2、辅助索引check duplicate

a、聚簇索引 primary key 是唯一的;非聚簇唯一索引,其索引也是唯一的。
b、若 insert 记录与聚簇索引项完全相同,并且聚簇索引项为删除项,则直接将其删除标记设置为 0,并在删除项上做 update。
c、若 insert 记录与非聚簇唯一索引项键值完全相同, 并且非聚簇索引项为删除项, 此时并不一定修改项状态,还需要判断两者对应的 primary key 是否相同,若 primary key 也相同,则重用项;否则,插入新项。
d、聚簇索引中,相同 primary key 取值的项,最多只有一项,不可能存在多项。
e、非聚簇唯一索引,索引键值相同的项可能有多项,但是这些项,其 primary  key 是不同的;而且,这些项,只有一个是有效项,其他项都为已删除的提交项。
f、聚簇索引的唯一性检查,只需要检测 insert 对应的记录即可,因为只有一项;非聚簇唯一索引的唯一性检测,需要向后检查多条键值相同记录

 
 

innodB的隐式锁

标签:

原文地址:http://www.cnblogs.com/zengkefu/p/5691230.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!