如果在transaction1(Tr1)进行一个

select * from table1 where id < 4 lock in share mode.

这里会在table1上加一个next_key lock(间隙锁)，基本原理是什么呢？大致是这样的，内存中有一个lock hash。是一个key（类似于tableid+pageid+offset）到value（所加的锁）--- 这就是行锁的原理。所以 id<4的话，会给0 1 2 4(假设当前数据库没有3)加上行锁，这样就保证了不会出现插入id=3.5这种事情的发生。

++++++++++++++++++++++++++++++++++++++++++

小插曲：

《万圣节 问题》

update table1 set c1=c1+2 where  c1<10; 如果使用index(c1)进行存取。

如果按照正常思路，取出第一条c1=1的将其+2，然后重新插入表中，同时要调整index(c1)。因为是按照索引顺序的一条一条的取出来的，

这样待会又会把刚刚更新过的数据，取出来再重新加了一次，导致错误的发生。----------这就是《万圣节问题》

解决方案：

使用RID list prefetch技术，先将要更改的数据取出来，放到一个temp table里面，每次取数据都是从temp table里面取，这样就不会重复的取出已经更新的数据了。

+++++++++++++++++++++++++++++++++++++++++++

所以 在transaction2(Tr2)进行一个

update table1 set id=5 where id=4;

会等待。。知道Tr1 commit之后才能更新成功。