innodB的隐式锁

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 对应的记录即可，因为只有一项；非聚簇唯一索引的唯一性检测，需要向后检查多条键值相同记录