create table 't' ('id' int(11) not null,'c' int(11) default null,'d' int(11) default null,primary key ('id'),key 'c' ('c')
) engine = InnoDB;insert into t values(0,0,0),(5,5,5),(10,10,10),(15,15,15),(20,20,20),(25,25,25);

该表除了主键id，还有索引c。

问下面的语句序列，是怎么加锁的，加的锁又是什么时候释放的呢？

begin;
select * from t where d = 5 for update;
commit;

这条语句会命中d=5这一行，对应主键id=5，因此在select语句执行完成后，id=5这一行会加一个写锁，并且由于两阶段锁协议，这个写锁会在执行commit语句的时候释放。

由于字段d上没有索引，因此这条查询语句会做全表扫描，那么，其他被扫描的不满足的行记录会不会被加锁？

幻读现象

如果旨在id=5这一行加锁，而其他行不加锁，在下面这个情况下：

session A执行了三次当前读，并且加上了写锁。

幻读指的是一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行。

幻读与不可重复读的区别

在同一个事务中，两次读取到的数据不一致的情况称为幻读和不可重复读。幻读是针对insert导致的数据不一致，不可重复读是针对 delete、update导致的数据不一致。

1、在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。

2、session B的修改结果被session A之后的select语句用当前读看到，不能称为幻读。幻读仅仅指"新插入的行"

幻读带来的问题

1、破坏语义。

session A在T1就说了，把d=5的行锁住，不准别的事务进行读写，此时被破坏。

因为如果我们这时插入d=5的数据，这条新的数据不在锁的保护范围之内。

2、数据一致性问题

锁的设计是为了保证数据的一致性，不止是数据库内部数据状态在此刻的一致性，还包含了数据和日志在逻辑上的一致性。

即使给所有行加上了锁，也避免不了幻读，这是因为给行加锁的时候，这条记录还不存在，没法加锁 。

也就是说即使把所有的记录都上锁了，还是阻止不了新插入的记录

如何解决幻读

产生的幻读的原因是：行锁只能锁住行

为了解决幻读问题，InnoDB引入新的锁：间隙锁(Gap Lock)

间隙锁，锁的就是两个值之间的空隙，比如在表t，初始化插入了6个记录，就产生了7个间隙：

执行：

select * from t where d = 5 for update

6个记录加上了行锁，同时加上了7个间隙锁。

间隙锁与行锁有点不一样

行锁可以分为读锁与写锁

与行锁有冲突关系的是另外一个行锁。

间隙锁不一样，间隙锁之间不存在冲突关系。

与间隙锁存在冲突关系的，是"向间隙中插入一个记录"这个操作。

举例：

由于表t中并没有c=7这个记录，所以session A加的是间隙锁(5,10)。而session B也是在这个间隙加的间隙锁，它们的目标都是保护这个间隙，不允许插入值，所以两者不冲突。

next-key lock

间隙锁与行锁合称next-key lock，每个lock都是前开后闭区间。间隙锁是开区间。

如上面我们插入数据，使用：

select * from t for update

形成了7个next-key lock，分别是：

(-∞,0]、(0,5]、(5,10]、(10,15]、(15,20]、(20, 25]、(25, +supremum]

supremum是一个不存在的最大值。

next-key lock 的引入解决了幻读问题，但是也带来了新的问题。

如，现在有这样一个业务逻辑：

任意锁住一行，如果这一行不存在的话就插入，如果存在这一行就更新它的数据。

begin;
select * from t where id = N for update;
--如果行不存在
insert into t values(N,N,N);
--如果行存在
update t set d = N set id = N;commit;

现在出现这个现象：这个逻辑一旦有并发，就会碰到死锁。

死锁的产生：两个间隙锁不冲突，相互等待行锁

执行流程：

1、session A执行select…for update语句，由于id=9这一行不存在，因此会加上间隙锁(5,10)

2、session B执行select…for update语句，同样会加上间隙锁(5,10)

3、session B插入(9,9,9)，被session A的间隙锁锁住，进入等待

4、session A擦汗如·插入(9,9,9),被session B的间隙锁锁住。

InnoDB死锁检测发现了这对死锁关系，然后报错返回了。

所以说间隙锁的引入可能会导致相同的语句锁住更大的范围，从而影响并发度。

间隙锁是在可重复读隔离级别下才会生效的。所以，你如果把隔离级别设置为读提交的话，就没有间隙锁了。 但同时，你要解决可能出现的数据和日志不一致问题，需要把 binlog 格式设置为 row。