MySQL事务和锁

1. 数据库事务

1.1 事务的典型场景

​ 在项目中，什么地方使用事务？是根据业务类型来使用的还是根据数据操作类型来使用的？无论你是在方法上加@Transactional注解，还是在xml文件中配置切面，还是直接用JDBC的方法。很多时候我们需要事务是因为我们希望涉及数据库的多个操作都成功，比如客户下单，会操作订单表，资金表，物流表等等，就需要放在一个事务中执行。

​ 一个非常典型的案例就是银行转账。如果我们把行内转账简化为一个账户余额减少，另一个账户余额增加的情况，那么这两个动作一定是同时成功或同时失败的，否则会造成会计科目不平衡。另一个例子：12306的连续换乘功能，两张票必须同时购买成功，只买到前半程或者只买到后半程是没有意义的。

1.2事务的定义

​ 事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，有一个有限的数据库操作序列构成。这里有两个关键点，1.所谓的逻辑单位，意味着它是数据库最小的工作单位，是不可再分的。2.它可能包含了一个或者多个DML语句，包括insert delete update。（单条DDL（create drop）和DCL（grant revoke）也会有事务）。

1.3 哪些存储引擎支持事务

​ 并不是所有的数据库或者所有的存储引擎都支持事务，它是作为一种特性出现的。在MySQL中除了做集群的NDB之外，只有InnoDB支持事务，这个也是它成为默认的存储引擎的一个重要原因。

1.4 事务的四大特性(ACID)

​ 1.原子性，Atomicity，也就是不可再分，因为原子是化学上（参加化学反应）最小单位。也就意味着我们对数据库的一系列操作，要么都成功，要么都失败，不可能出现部分成功的情况。问题是如果前面一个成功了，后面的操作失败了，怎么让它全部失败？这个时候我们必须要回滚。原子性在InnoDB中是通过undo log来实现的，他记录了数据修改之前的值（逻辑日志），一旦发生异常，就可以用undo log来实现回滚操作。

​ 2.隔离性，Isolation，我们有了事务的定义后，在数据库中会有很多的事务同时去操作我们的同一张表或者同一行数据，必然会产生一些并发或者干扰的操作。我们对隔离性的定义，就是这些很多个的事务，对表或者行的并发操作，应该是透明的，互相不干扰的。比如两个人给青山转账100，开启两个事务，都拿到了青山账户的余额1000，然后各自基于1000加100，最后结果是1100，就出现了数据混乱的问题。

​ 3.持久性，Durability，事务的持久性是什么意思？我们对数据库的任意的操作，增删改，是要事务提交成功，那么结果就是永久性的，不可能因为数据库掉电，宕机，意外重启，又能变成原来的状态。这个就是事务的持久性。持久性是通过redo log和double write buffer（双写缓冲）来实现的，我们操作数据的时候，会先写到内存的buffer pool中，同时记录redo log，如果在刷盘之前出现异常，在重启后就可以读取到redo log的内容，写入到磁盘，保证数据的持久性。当然，恢复成功的前提是数据页本身没有损坏，是完整的，这个通过双写缓冲保证。需要注意的是，原子性，隔离性，持久性，最后都是为了实现一致性。

​ 4.一致性，consistent，指的是数据库的完整性约束没有被破坏，事务执行前后都是合法的数据状态。数据库自身提供了一些约束：比如主键必须是唯一的，字段长度符合要求。另外还有用户自定义的完整性，用户自定义的完整性通常要在代码中控制，例如金额不能小于0等。

1.5数据库什么时候出现事务

​ 当执行一条更新语句，实际上，它不仅自动开启了事务，而且还自动提交了，所以最终写入了磁盘。这个是开启事务的第一种方式，增删改的语句会自动开启事务，当然是一条SQL一个事务。注意每个事务都是有编号的，这个编号是一个整数，有递增的特性。如果把多条SQL放在一个事务中，就要手动开启事务。手动开启事务有两种方式：一种是用begin；一种是用start transaction。结束事务也有两种方式：一种是回滚事务rollback，事务结束；另一种是提交事务commit，事务结束。

​ InnoDB中有一个autocommit的参数（分为两个级别，session和global级别）

show variables like 'autocommit';

​ 它的默认值是ON。这个参数的意义是是否自动提交。如果它的值是true/ON的话，会自动提交事务。如果设置为false/OFF的话，那么数据库的事务就需要我们手动结束，用rollback或commit。

​ 还有一种情况，客户端的连接断开的时候，事务也会结束。

1.6事务并发会带来哪些问题？

​ 有两个事务，一个编号2573，另一个是2674。在第一个事务中，它首先通过where id=1的条件查询一条数据，返回name=Ada，age=16的这条数据，然后第二个事务，它通过一个update的语句，把id=1的数据的age改成了18，但是没有提交。

​ 这时，在第一个事务中，它再次执行相同的查询操作，发现数据发生了变化，获取到的数据age变成了18.那么，这种在一个事务中，由于其他的时候修改了数据并且没有提交，而导致了前后两次读取数据不一致的情况，这种事务并发的问题，我们把它定义为脏读。如果在转账的案例中，我们第一个事务基于读取到的第二个事务未提交的余额进行了操作，但是第二个事务进行了回滚，这个时候就会导致数据不一致。

​ 同样是两个事务，第一个事务通过id=1查询到了一条数据。然后第二个事务中执行了一个update操作，执行了update以后它通过一个commit提交了修改。然后第一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，就像这里，age到底是16还是18，那么这种事务并发带来的问题，把它叫做不可重复读。

​ 在第一个事务中我们执行了一个范围查询，这时满足条件的数据只有一条。在第二个事务中，插入了一行数据，并且提交了。重点：插入了一条数据。在第一个事务再去查询时，它发现多了一行数据。一个事务前后两次读取数据不一致，是由于其他事务插入数据造成的，这种情况叫做幻读。

不可重复读和幻读的区别在哪里？修改或删除造成的读不一致叫做不可重复读，插入造成的读叫做幻读。

这里有两点需要说明：

1. 一个事务读取到其他事务最新提交的数据，这不是正常的吗？当然是正常的，所以这里讨论的是读一致性。读一致性的意义就是一个事务的select操作跟其他事务没有瓜葛，你不需要修改数据，所以不需要获取最新的数据，这样能够提高并发性能。

2. 如果在第一个事务中，select以后，再执行一个update，就能获取到第二个事务的最新数据，这个怎么解释？同样的，这个页脱离了读一致性的讨论范畴。如果要修改数据。必然会读取到最新的数据，也会影响其他的事务。

所以这里要不要修改，要不要读取到最新的数据，是一个区别点。目前我们讨论的都是一个事务中多次重复读取。

​ 小结：无论是脏读，不可重复读，幻读，他们都是数据库的读一致性问题，都是在一个事务中前后两次读取出现了不一致的情况。读一致性的前提，必须要由数据库提供一定的事务隔离机制来解决。就像我们去饭店吃饭，基本的设施和卫生保证都是饭店提供的。那么我们使用的数据库，隔离性的问题页必须由数据库帮助我们解决。

1.7SQL92标准事务隔离级别定义

​ 美国国家标准协会（ANSI）制定了一个SQL标准，也就是说建议数据库厂商都按照这个标准，提供一定的事务隔离级别，来解决事务并发的问题。这个SQL标准有很多版本，大家最熟悉的是SQL92标准。

​ 这个表格里面定义了四个隔离级别，右边P1 P2 P3计师代表事务并发的3个问题，脏读，不可重复读，幻读。Possible代表在这个隔离级别下，这个问题有可能发生，换句话说就是没有解决这个问题。Not Possiable就是解决了这个问题。

我们详细的分析这4个隔离级别是怎么定义的。

1. Read Uncommitted（未提交读），一个事务可以读取到其他事务为提交的数据，会出现脏读，所以叫做RU，没有解决任何问题。

2. Read Commited（已提交读），就是一个事务只能读取到其他事务已提交的数据，不能读取其他事务未提交的数据，解决了脏读的问题，但是会出现不可重复读的问题。

3. Repeatable Read（可重复读），它解决了不可重复读的问题，也就是在同一事务中多次读取的数据结果是一样的，但是没有解决幻读的问题

4. Serializable（串行化），这个隔离级别下，所有的事务都是串行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决了所有问题。

事务的隔离级别是可以修改的：

set global transaction isolation level read uncommitted;
set global transaction isolation level read committed;
set global transaction isolation level repeatable read;
set global transaction isolation level serializable;

​ 这个是SQL92的标准，但是不同的数据库厂商或者存储引擎的实现有一定的差异，比如Oracle中就只有两种RC（已提交读）和Serializable（串行化）。

1.8 InnoDB事务隔离级别的实现

事务隔离级别	脏读	不可重复读	幻读
未提交读(Read Uncommitted)	可能	可能	可能
已提交读(Read Committed)	不可能	可能	可能
可重复读(Repeatable Read)	不可能	不可能	对InnoDB不可能
串行化(Serializable)	不可能	不可能	不可能

​ InnoDB支持的4个隔离级别和SQL92定义的完全一致，隔离级别越高，事务的并发度越低。唯一的区别是InnoDB在RR级别就解决了幻读的问题。也就是说不需要使用串行话去解决所有问你题，既保证了数据的一致性，又支持较高的并发度，这个就是InnoDB默认使用RR作为事务隔离级别的原因。

1.9 读一致性解决方案

​ 如果要解决读一致性的问题，保证一个事务中前后两次读取数据结果一致，实现事务隔离，总体上有以下两大类方案。

1.9.1 LBCC

​ 既要保证前后两次读取数据一致，那么我读取数据时锁定我要操作的数据，不允许其他的事务修改就行了。这种方案叫做基于锁的并发控制Lock Based Concurrency Control（LBCC）。

​ 如果仅仅是基于锁来实现事务隔离，一个事务读取得时候不允许其他事务修改，那就意味着不支持并发得读写操作，而我们得大多数应用都是读多写少得，这样会极大得影响操作数据得效率。

1.9.2 MVCC

​ 第二种，如果要让一个事务前后两次读取得数据保持一致，那么我们可以在修改数据之前给它建立一个备份或者快照，后面再来读取这个快照就行了。这种方案我们叫做多版本的并发控制Multi Version Concurrency Control（MVCC）。MVCC的原则：

一个事务能看到的数据版本：

1. 第一次查询之前已经提交的事务的修改

2. 本事务的修改

一个事务不能看见的数据版本：

1. 在本事务第一次查询之后创建的事务（事务ID比本事务ID大）

2. 活跃的（未提交的）事务的修改

​ MVCC的效果：我们可以查到在我这个事务之前已经存在数据，即使它在后面被修改删除了，而在我这个事务之后新增的数据，我是查不到的。所以我们才把这个叫做快照，不管别的事务做任何增删改查的操作，它只能看到第一次查询时看到的数据版本。

​ 分析一下MVCC的原理。首先，InnoDB的事务都是由编号的，而且会不断递增。InnoDB为每行记录都实现了两个隐藏字段：

​ 1.DB_TRX_ID，6字节：事务id，数据是在哪个事务插入或者修改为新数据的，就记录为当前事务ID。

​ 2.DB_ROLL_PTR，7字节：回滚指针，我们把它理解为删除版本号，数据被删除或记录为旧数据时，记录当前事务ID，没有修改或者删除的时候是空。

id	name	DB_TRX_ID	DB_ROLL_PTR
1	aaa	01	NULL

当第一个事务，初始化数据（检查初始数据）

Transaction 1
begin; insert into mvcctest values(null, ‘qs’); insert into mvcctest values(null, ‘hh’); commit;

此时的数据，创建版本是当前事务ID（假设事务编号是1），删除版本为空：

id	name	创建版本	删除版本
1	qh	1	undefined
2	hh	1	undefined

第二个事务，执行第一次查询，读取到两条原始数据，这时事务ID是2：

Transaction 2
begin; select * from mvcctest; –(1)第一次查询

第三个事务，插入数据：

Transaction 3
begin; insert into mvcctest values(NULL, ‘tom’); commit

此时的数据，多了一条tom，它的创建版本号是当前事务编号，3：

id	name	创建版本	删除版本
1	qs	1	undefined
2	hh	1	undefined
3	tom	3	undefined

第二个事务，执行第二次查询：

Transaction 2
select * from mvcctest; –(2)第二次查询

​ MVCC的查找原则：只能查找创建时间小于等于当前事务ID的数据，和删除时间大于当前事务ID的行（或未删除）。也就是不能查到在我的事务开始之后插入的数据，tom的创建ID大于2，所以还是只能查到两条数据。

第四个事务，删除数据，删除了id=2 hh这条记录：

Transaction 4
begin; delete from mvcctest where id=2; commit;

此时的数据，hh的删除版本被记录为当前事务ID，4，其他数据不变：

id	name	创建版本	删除版本
1	qs	1	undefined
2	hh	1	4
3	tom	3	undefined

在第二个事务中，执行第三次查询：

Transaction 2
select * from mvcctest; (3)第三次查询

​ 查找规则：只能查找创建时间小于等于当前事务ID的数据，和删除时间大于当前事务ID的行（或未删除）。也就是，在我事务开始之后删除的数据，所以huihui依然可以查出来。所以还是查出两条数据。

​ 第五个事务，执行更新操作，这个事务ID是5：

Transaction 5
begin; update mvcctest ser name = ‘盆玉艳’ where id= 1; commit;

此时的数据，更新数据时，旧数据的删除版本被记录为当前事务ID5（undo），产生了一条新数据，创建ID为当前事务ID5：

id	name	创建版本	删除版本
1	qs	1	5
2	hh	1	4
3	tom	3	undefined
1	盆玉艳	5	undefined

第二个事务，执行第四次查询：

Transaction 2
select * from mvcctest; (4)第四次查询

​ 查找规则：只能查找创建时间小于等于当前事务ID的数据，和删除时间大于当前事务ID的行（或未删除）。因为更新后的数据盆鱼宴创建版本大于2，代表是在事务之后增加的，查不出来。而旧数据qingshan的删除版本大于2，代表是在事务之后删除的，可以查出来。

​ 通过以上演示可以看到，通过版本号的控制，无论其他事务是插入，修改，删除，第一个事务查询到的数据都没有变化。这个是MVCC的效果，当然，这里是一个简化的模型。假设一条数据修改了3次，两次提交了一次未提交，每次修改之后都有开启一个事务去查询，那么事务2，4，6查到的数据会有不一样。

trx_id	SQL
trx1	update user_info set name = ‘penyuyan’ where id =1; commit;
trx2	select name from user_info where id = 1;
trx3	update user_info set name=’wuyanzu’ where id = 1; commit;
trx4	select name from user_info where id = 1;
trx5	update user_info set name=’liudehua’ where id = 1; 未提交
trx6	select name from user_info where id = 1;
	trx2、4、6再各查一次

​ InnoDB中，一条数据的旧版本，是存放在undo log中。因为修改了多次，这些undo log回形成一个链条，叫做undo log链，现在undo log中有刘德华，吴彦祖，盆鱼宴。所以前面说的DB_ROLL_PTR，它其实指向undo log链的指针。

​ 第二个问题，事务2，4，6最后再查一次，他们去undo log链找数据时。拿到的数据是不一样的。再这个undo log链里面，一个事务怎么判断哪个版本的数据是它应该读取的？

回想一下MVCC的规则：

一个事务能看到的数据版本：1，第一次查询之前已经提交的事务的修改；2，本事务的修改。

一个事务不能看到的数据版本：1，本事务第一次查询之后创建的事务（事务ID比我的事务ID大）；2，活跃的（未提交的）事务的修改。

​ 所以，必须要有一个数据结构，把本事务ID，活跃事务ID，当前系统最大事务ID存起来，这样才能实现判断。这个数据结构叫Read View（可见性视图），每个事务都维护一个自己的Read View。

m_ids：表示在生成ReadView时当前系统活跃的读写事务的事务id列表。

min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务ID，也就是m_ids中的最小值。

mmax_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。

creator_trx_id：表示生成该ReadView的事务的事务id。

有了这个数据结构后，事务判断可见性的规则是这样的：

0，从数据的最早版本开始判断（undo log）。

1，数据版本的trx_id = creator_trx_id，本事务修改，可以访问。

2，数据版本的trx_id < min_trx_id（未提交事务的最小ID），说明这个版本是生成ReadView已经提交，可以访问。

3，数据版本的trx_id > max_trx_id（下一个事务ID），这个版本是生成ReadView之后才开启的事务建立的，不能访问。

4，数据版本的trx_id在min_trx_id和max_trx_id之间，看看是否在m_ids中。如果在，不可以。如果不在，可以。

5，如果当前版本不可见，就找undo log链中的下一个版本。

​ 注意：RR中ReadView是事务第一次查询时建立的。RC的ReadView是事务每次查询的时候建立的。Oracle，Postgres等等其他数据库都有MVCC实现。需要注意，在InnoDB中，MVCC和锁是协同使用的，这两种方式并不是互斥的。

2 InnoDB锁的基本类型

2.1 锁的粒度

​ InnoDB和MyISAM支持的锁的类型是不同的。InnoDB同时支持表锁和行锁，MySIAM只支持表锁，用lock table的语法加锁。

lock talbes xxx read;
lock tables xxx write;
unlock tables;

2.2 锁的类型

https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html

​ 官网把锁分成了8类。把前面的两个行级别锁（Shared and Exclusive Locks），和两个表级别的锁（Intention Locks）称为锁的基本模式。后面三个Record Locks，Gap Locks，Next-Key Locks，我们把它们叫做锁的算法。

​ 插入意向锁（Insert Intention Locks）：是一个特殊的间隙锁。间隙锁不允许插入数据，但是插入意向锁允许多个事务同时插入数据到同一个范围，比如（4，7），一个事务插入5，一个事务插入6，不会发生锁等待。

​ 自增锁（AUTO-INC Locks）：是一种特殊的表锁，用来防止自增字段重复，数据插入以后就会释放，不需要等到事务提交才释放。如果需要选择更快的子增值生成速度或者更加连续的子增值，就要通过修改自增锁的模式改变。

show variables like 'innodb_autoinc_lock_mode'

​ 0：traditional（每次都会产生表锁）

​ 1：consecutive（会产生一个轻量锁，simple insert会获得批量的锁，保证连续插入，默认值）

​ 2：interleaved（不会锁表，来一个处理一个，并发最高）

​ Predicate Locks for Spatial Indexes是5.7版本中新增的一种数据类型的索引的锁。

2.3 共享锁

​ 第一个行级别的锁就是Shared Locks（共享锁），获取了一行数据的读锁以后，可以用来读取数据，所以也叫做读锁，注意不要在加上了读锁以后去写数据，不然的话可能会出现死锁的情况。而且多个事务可以共享一把读锁。共享锁的作用：因为共享锁会阻塞其他事务的修改，所以可以用在不允许其他事务修改数据的情况（共享锁和写锁互斥的例子后面再看）。我们可以用select …… lock in share mode；的方式手工加上一把读锁。释放锁有两种方式，只要事务结束就会自动释放锁，包括提交事务和结束事务

Transaction 1	Transaction 2
begin;
select * from student where id =1 lock in share mode;
	begin;
	select * from student where id = 1 lock in share mode; //OK

2.4 排他锁

​ 第二个行级别的锁叫做Exclusive Locks（排他锁），它是用来操作数据的，所以又叫做写锁。只要一个事务获取了一行数据的排他锁，其他事务就不能再获取这一行数据的共享锁和排他锁。加锁的方式有两种，第一种是自动加排他锁，增删改都会默认加上一个排他锁。还有一种是手工加锁，我们用一个FOR UPDATE给一行数据加上一个排他锁，这个无论是在我们的代码中还是操作数据的工具中都比较常用。释放锁和前面是一样的。

Transaction 1	Transaction 2
begin;
update student set sname=’fdasfd’ where id = 1;
	begin;
	select * from student where id=1 lock in share mode; //blocked select * from student where id=1 for update; //blocked delete from student where id=1 //blocked

2.5 意向锁

​ 意向锁是由数据库自己维护的。也就是说，当我们给一行数据加上共享锁之前，数据库会自动在这张表上面加上意向共享锁。当我们给一行数据加上排他锁之前，数据库会自动在这张表上面加上一个意向排他锁。反过来，如果一张表上至少有一个意向共享锁，说明其他事务给其中的某些数据加上了共享锁；如果表上至少有一个意向排他锁，说明其他事务给其中的某些数据行加上了排他锁。

​ 意向锁和意向锁是不冲突的，意向锁和行锁也不冲突。那么这两个表级别的锁有什么意义？如果没有意向锁的话，当我们准备给一张表加上表锁时，我们首先需要去判断有没有其他事务锁定了某些行，如果有的话，肯定不能加上表锁。那么这时我们就要去扫描整张表才能确定能不能成功加上一个表锁，如果数据量很大，那么加表锁的效率就非常低。但是我们引入意向锁后就不一样了，我们只要判断这张表上是否有意向锁，如果有直接返回失败。如果没有就可以加锁成功。所以InnoDB中的表锁，我们可以把它理解为一个标志（就像火车上卫生间有没有使用的灯），是用来提高加锁效率的。

Transaction 1	Transaction 2
begin;
select * from student where id=1 for update;
	beginl
	lock tables student write; //blocked unlock tables; //释放表锁的方式

​ 数据库锁跟java中的锁是一样的，是为了解决资源竞争的问题，java中的资源是对象，数据库的资源是数据表或者数据行。所以锁是用来解决事务对数据的并发访问问题的。

3 行锁的原理

​ 有三张表，一张没有索引的t1，一张有主键索引的t2，一张有唯一索引的t3

1.没有索引的表（假设锁住记录）

​ 假设InnoDB的行锁是锁住了一行数据或者一条记录。先看一下t1的表结构，它有两个字段，int类型的id和varchar类型的name。里面有4条数据1，2，3，4。

Transaction 1	Transaction 2
begin;
select * from t1 where id = 1 for update;
	select * from t1 where id=3 for update; //blocked
	insert into ‘t1’(‘id’,’name’) values(5, ‘5’); //blocked

​ 在两个会话中手工开启两个事务。第一个事务中我们通过where id = 1锁住第一行数据。第二个事务中，我们尝试给id=3的这一行数据加锁，被阻塞。插入一条id=5的数据，被阻塞。结果第二个事务的加锁操作被阻塞了，说明InnoDB的行锁锁住的不是Record。那为啥在没有索引或者没有用到索引的情况下，会锁住整张表？这个问题后续解释。

2.有主键索引的表

​ t2的表结构。字段是一样的，不同的地方是id上创建了一个主键索引。里面的数据是1，4，7，10.

Transaction 1	Transaction 2
begin;
select * from t2 where id = 1 for update;
	select * from t2 where id=1 for update; //blocked
	select * from t2 where id=4 for update //OK

第一种情况，使用相同的id值去加锁，冲突；使用不同的id加锁，加锁成功。

3.唯一索引（假设锁住字段）

t3的表结构。字段还是一样的，id上创建了一个主键索引，name上创建了一个唯一索引。里面数据1，4，7，10.

Transaction 1	Transaction 2
begin;
select * from t3 where name=’4’ for update;
	select * from t3 where name=’4’ for update; //blocked
	select * from t3 where id=4 for update //blocked

​ 第一个事务中我们通过name字段去锁定值是4的数据。第二个事务中尝试获取一样的排他锁，失败。然后用id=4去给这行数据加锁，被阻塞，说明行锁锁住字段的推测也是错的。

​ 既然锁住的不是record，也不是column，InnoDB的行锁到底锁住了什么？在这三个案例中，他们的差异就在于表结构，其实答案就是索引，InnoDB的行锁是**通过锁住索引实现的。还有两个问题没有解决：

​ 1.为什么表中没有索引的时候，锁住一行数据会导致锁表？因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。

​ 2.为什么通过唯一索引给数据行加锁，主键索引也会被锁住？因为我们通过辅助索引锁定一行数据时，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然后也锁定。本质上是因为锁定的是同一行数据，是相互冲突的。

4 行锁的算法

​ 我们先看一下测试用表t2，其中有个主键，插入4行数据，主键id分别是1，4，7，10.

​ 首先，先普及一下三种范围的概念。因为我们用主键索引加锁，我们这里划分标准就是主键索引的值。

​ 这些数据库中存在的主键值，我们把它叫做Record，记录，那么我们这里就有4个Record。根据主键，这些存在的Record隔开的数据不存在的区间，我们叫做Gap，间隙，它是一个左开右开的区间。假如我们有N个Record，那么我们就有N+1个Gap。最后一个，间隙（Gap）连同它左边的记录（Record），我们把它叫做临键的区间，它是左开右臂=闭得区间。整型的主键索引，它是可以排序的，所以才有这种区间，如果我的主键索引不是整型，是字符怎么办？任何一个字符集，都有相应得排序规则：

4.1 记录锁(Record Locks)

​ 当对于唯一性的索引（包括唯一索引和主键索引）使用等值查询，精准匹配到一条记录的时候，这时使用的就是记录锁。

​ 使用不同的key去加锁，不会冲突，它只锁住这个record。图片上红的字就是使用这种锁的条件。

4.2 间隙锁(Gap Locks)

​ 当查询的记录不存在，没有命中任何一个record，无论是用等值查询还是范围查询时，它使用的都是间隙锁。

​ 举个例子，where id > 4 and id < 7, where id = 6。

Transaction 1	Transaction 2
begin;
select * from t2 where id=6 for update;
	insert into ‘t2’(‘id’,’name’) values(5,’6’); //blocked insert into ‘t2’(‘id’,’name’) values(6,’6’); //blocked select * from t2 where id=6 for update; //OK
select * from t2 where id > 20 for update;
	insert into ‘t2’(‘id’,’name’) values(11,’6’); //blocked

当查询不存在时使用间隙锁。注意，间隙锁主要是阻塞插入insert，相同的间隙锁之间不冲突。

4.3 临键锁(Next-Key Locks)

​ 当我使用了范围查询，不仅仅命中了Record记录，还包含了Gap间隙，在这种情况下我们使用的就是临键锁，它是Mysql中默认的行锁算法，相当于记录锁加上间隙锁。唯一性索引，等值查询匹配到一条记录时退化为记录锁。没有匹配到记录时退化成间隙锁。

​ 比如使用>5，<9，它包含了记录不存在的区间，也包含了一个Record 7.

Transaction 1	Transaction 2
begin;
select from t2 where id>5 and id<9 for update
	begin;
	select * from t2 where id=4 for update; //OK insert into ‘t2’(‘id’,’name’) values(6, ‘6’); //blocked insert into ‘t2’(‘id’,’name’) values(8, ‘6’); //blocked select * from t2 where id=10 for update; //blocked

​ 临键锁，锁住最后一个key的下一个左开右闭区间。

select * from t2 where id > 5 and id < 7 for update; --锁住(4,7] 和(7,10]
select * from t2 where id > 8 and id < 10 for update; --锁住(7,10] 和(10,正无穷)

为什么要锁住下一个左开右闭区间？就是为了解决幻读的问题。

4.4 InnoDB事务隔离级别的实现

​ 所以，InnoDB的RR级别能够解决幻读的问题，就是用临键锁实现的。

​ 最后总结一下四个事务隔离级别的实现：

​ 1.Read Uncommited：RU隔离级别，不加锁

​ 2.Serializable：所有的select语句都会被隐式的转化为select ……in share mode，会和update，delete互斥。

​ 3.Repeatable Read：RR隔离级别下，普通的select使用快照读（snapshot），底层使用MVCC来实现。加锁的select（select … in share mode/select …for update）以及更新操作update，delete等语句使用当前读（current read），底层使用记录锁，或者间隙锁或者临键锁。

​ 4.Read Commited：RC隔离级别下，普通的select都是快照读（MVCC）。加锁的select都使用记录锁，因为没有Gap Lock。除了两种特殊情况——外键约束检查（foreign-key constraint checking）以及重复键检查（duplicate-key checking）时会使用间隙锁封锁区间，所以RC会出现幻读问题。

5 事务隔离级别的选择

​ RU和Serializable肯定不能使用。为什么有些公司要用RC？

​ RC和RR主要有几个区别：

​ 1.RR的间隙锁会导致锁定范围的扩大。

​ 2.条件列未使用到索引，RR锁表，RC锁行

​ 3.RC的“半一致性”（semi-consistent）读可以增加update操作的并发性。

​ 在RC中，一个update语句，如果督导一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足update的where条件。若满足（需要更新），则MuSQLhi重新发起一次读操作，此时会读取行的最新版本（并加锁）。

​ 实际上，如果能够正确的使用锁（避免不使用索引去加锁），只锁定需要的数据，用默认的RR级别就可以了。在我们使用锁的时候，有个问题时需要注意和避免的，我们知道，排他锁由互斥的特性。一个事务或者说一个线程持有锁时，会阻止其他的线程获取锁，这时会造成阻塞等待，如果训话等待，会有可能造成死锁。

6 死锁

6.1 锁的释放与阻塞

​ 锁是在事务结束（commit，rollback）或者客户端断开连接的时候释放。控制锁的等待时间，默认是50秒

show variables like 'innodb_lock_wait_timeout';

6.2 死锁的发生与检测

​ 在发生死锁时，InnoDB一般通过算法（wait-for graph）自动检测到。 死锁产生的条件：

​ （1）同一时刻只能有一个事务持有这把锁

​ （2）其他事务需要在这个事务释放锁之后才能获取锁，而不可以强行剥夺

​ （3）当多个事务形成等待环路的时候，即发生死锁。

​ 实际上，发生死锁的原因很多，但是都满足以上3个条件这个也是表锁是不会发生死锁的原因，因为表锁的资源都是一次性获取的。

6.3 查看锁信息（日志）

首先，SHOW STATUS命令中，包括了一些行锁的信息。

Show命令是一个概要信息。InnoDB还提供了三张表来分析事务与锁的情况：

更加详细的锁信息，开启标准监控和锁监控：

set global innodb_status_output=ON;
set global innodb_status_output_locks=ON;

​ 如果一个事务长时间持有锁不释放，可以kill事务对应的线程ID，也就是INNODB_TRX表中的trx_mysql_thread_id。当然，死锁的问题不能每次都靠kill解决，我们应该尽量在编码的过程中避免。

6.4 死锁的避免

​ （1）在程序中，操作多张表时，尽量以相同的顺序来访问（避免形成等待环路）

​ （2）批量操作单张表数据时，先对数据进行排序（避免形成等待环路）

​ （3）申请足够级别的锁，如果要操作数据，就申请排他锁

​ （4）尽量使用索引访问数据，避免没有where条件的操作，避免锁表

​ （5）如果可以，大事务化成小事务

​ （6）使用等值查询而不是范围查询查询数据，命中记录，避免间隙锁对并发的影响。