点击链接查看数据库其他内容：
MySQL事务与锁机制 目录
4 事务
4.1 事务
事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由一个有限的数据库操作序列(DDL等)构成。
存储引擎中，InnoDB支持事务。
4.1.1 事务的四大特性
（1） 原子性（Atomicity）
即不可再分性。即对数据库的一系列操作，要么都成功，要么都失败，不可能出现部分成功或者部分失败的情况。
当出现部分失败的情况时，使用回滚。
在InnoDB里面通过undo log实现，记录了数据修改之前的值（逻辑日志），一旦发生异常，就可以使用undo log实现回滚操作。
（2）一致性（Consistent）
指数据库的完整性约束没有被破坏，事务执行前后都是合法的数据状态。比如主键必须是唯一的，字段长度符合要求等。
除数据库自身的完整性约束外，还有用户自定义的完整性。
（3）隔离性（Isolation）
隔离性，即很多个事务，对表或者行的并发操作，应该是透明的，互不干扰的。
（4）持久性（Durable）
对数据库的任何操作，只要事务提交成功，那么结果是永久性的。
持久性通过redo log来实现，操作数据时，会先写到内存的Buffer Pool中，同时记录redo log，如果在刷盘之前出现异常，在重启后就可以读取redo log的内容，写入磁盘，保证数据的持久性。
原子性、隔离性、持久性，最后都是为了实现一致性。
4.1.2 数据库什么时候出现事务
开启事务的两种方式：
（1）自动开启和自动提交
InnoDB里面有一个autocommit参数，分为两个级别（session级别和global级别）。
show variables like 'autocommit ';其默认值是ON。为自动提交事务，即当我们操作数据时，会自动开启一个事务，和自动提交事务。
set session autocommit = on/off; -- 设定事务是否自动开启
（2）手动开启事务
begin 或是
start transaction （提供更多的参数）
（3）结束事务
第一种就是提交一个事务：commit
另一种就是rollback，回滚的时候，事务也会结束。
（图形化界面中，关闭窗口也会结束事务）
4.2 事务并发带来的问题
4.2.1 脏读
在一个事务里面，读取到了其他操作修改了数据并且没有提交的数据，导致了前后两次读取数据不一致的情况，叫做脏读。
4.2.2 不可重复读
第一个事务第一次查询到数据之后，第二个事务提交了修改，导致第一个事务第二次读取数据时，读取到了其他事务已提交的数据（更新和删除），导致前后两次数据不一致的情况，这种问题叫做不可重复读。
4.2.3 幻读
一个事务前后两次读取数据不一致，是由于其他事务插入数据造成的，这种情况称为幻读。
事务并发的三大问题其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。
4.3 事务隔离级别
SQL92 ANSI/ISO标准：
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
（1）Read Uncommitted（未提交读） --未解决任何并发问题
（一个事务可以读取到其他事务未提交的数据）事务未提交的数据对其他事务也是可见的，会出现脏读
（2）Read Committed（已提交读） --解决脏读问题
一个事务开始之后，只能看到已提交的事务所做的修改，会出现不可重复读
（3）Repeatable Read (可重复读) --解决不可重复读问题
在同一个事务中多次读取同样的数据结果是一样的，这种隔离级别未定义解决幻读的问题
（4）Serializable（串行化） --解决所有问题
最高的隔离级别，通过强制事务的串行执行，也就是对数据的操作排队执行，不存在事务并发，会造成数据库性能下降。
MySQL InnoDB对隔离级别的支持
4.4 MVCC
如果要解决读一致性的问题，保证一个事务中前后两次读取数据结果一致，实现事务隔离，应该怎么做？
4.4.1 两大实现方案
（1）LBCC
第一种，即读取数据时，锁定我要操作的数据，不允许其他事务修改。
这种方案称为基于锁的并发控制 Lock Based Concurrency Control(LBCC)。
（2）MVCC（重要）
生成一个数据请求时间点的一致性数据快照（Snapshot)，并用这个快照来提供一定级别（语句级或事务级）的一致性读取，称为多版本的并发控制（MVCC）Multi VersionConcurrency Control。
4.4.2 MVCC
其核心思想是：
我可以查到我这个事务开始之前已经存在的已提交的数据，即使后来被修改或者删除了。在我这个事务之后新增的数据，我是查不到的。
InnoDB为每一行记录都创建了两个隐藏字段。
DB_TRX_ID，6字节：插入或更新行的最后一个事务的事务ID，事务编号是自动递增的（理解为创建版本号，在数据新增或者修改为新数据的时候，记录当前事务的ID）。
DB_ROLL_PTR，7字节：回滚指针（理解为删除版本号，数据被删除或记录为旧数据时，记录当前事务ID）。
（1）示例
1.第一个事务，初始化数据
此时的数据：创建版本号为事务ID（1），删除版本号 未定义
第二个事务，执行第一次查询，读取到两条原始数据，此时事务ID为2
第三个事务，插入数据：
此时数据多了一条数据为Tom，其创建版本号是当前事务编号为3：
第二个事务，执行第二次查询：
发现查不到新增的数据。
MVCC特性：
只能查找到本事务的修改，和在第一次查询之前就已经提交的事务的修改。
也就是不能查到在当前事务开始之后插入的数据。
第四个事务，删除数据。删除了id = 2 jack的这条数据。
此时的数据，jack的删除版本被记录为当前事务ID为4，其他数据不变。
第二个事务中，执行第三次查询：
MVCC查找规则：
只能查到本事务的修改，和在第一次查询之前就已经提交的事务的修改。
第五个事务，执行更新操作，事务ID为5.
此时的数据，更新数据时，旧数据的删除版本号为当前事务ID为5（undo），产生了一条新数据，创建ID为当前事务ID为5.
第二个事务，执行第4次查询。
查找规则：
只能查到本事务的修改，和在第一次查询之前就已经提交的事务的修改。
【通过版本号的控制，无论其他事务是插入、修改、删除，第一个事务查询到的数据都没有变化】
5 MySQL InnoDB 锁机制
在InnoDB中，MVCC和锁是协同使用的。
5.1 锁介绍
5.1.1 锁的粒度
表锁与行锁的区别：
锁定粒度：表锁 > 行锁
加锁效率：表锁 > 行锁
冲突概率：表锁 > 行锁
并发性能：表锁 < 行锁
5.1.2 InnoDB锁类型
问题：MyISAM和InnoDB分别支持什么粒度的锁？
MyISAM只支持表锁
InnoDB既支持行锁也支持表锁
共享锁（行锁）：Shared Locks
排它锁（行锁）：Exclusive Locks
意向共享锁（表锁）：Intention Shared Locks
意向排它锁（表锁）：Intention Exclusive Locks
5.1.3 行锁算法
记录锁 Record Locks
间隙锁 Gap Locks
临键锁 Next-key Locks
5.2 锁的基本类型
5.2.1共享锁（读锁——S锁）
Shared Locks(共享锁)，我们获取了一行数据的读锁以后，可以用来读取数据,所以它也叫做读锁。
用select ......lock in share mode;的方式手工加上一把读锁。
释放锁有两种方式，只要事务结束，锁就会自动事务，包括提交事务和结束事务。
5.2.2 排它锁（写锁——X锁）
Exclusive Locks(排它锁)，它是用来操作数据的，所以又叫做写锁。只要一个事务获取了一行数据的排它锁，其他的事务就不能再获取这一行数据的共享锁和排它锁。不能与其他锁共存。
增删改，都会默认自动加上一个排它锁。
手工加锁，用FOR UPDATE给一行数据加上一个排它锁，这个无论是在我们的代码里面还是操作数据的工具里面，都比较常用。
释放锁的方式跟前面是一样的。
使用：
show variables like ‘innodb_lock_wait_timeout’；获取排它锁阻塞的最大时长为50s。
5.2.3 意向锁（表级别锁）
当我们给一行数据加上共享锁之前，数据库会自动在这张表上面加一个意向共享锁（IS）。
当我们给一行数据加上排他锁之前，数据库会自动在这张表上面加一个意向排他锁（IX）。
反过来说:
如果一张表上面至少有一个意向共享锁，说明有其他的事务给其中的某些数据行加上了共享锁。
如果一张表上面至少有一个意向排他锁，说明有其他的事务给其中的某些数据行加上了排他锁。
意向锁是由数据引擎自己维护的，用户无法手动操作意向锁 。
意向共享锁（Intention Shared Lock，简称IS锁）
表示事务准备给数据行加入共享锁，也就是说一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（Intention Exclusive Lock，简称IX锁）
表示事务准备给数据行加入排他锁，说明事务在一个数据行加排他锁前必须先取得该表的IX锁。
select * from t2 where id =4 for update:
TABLE LOCK table ‘table’.'t2' trx id 24467 lock mode lx
RECORD LOCKS space id 64 page no 3 n bits 72 index PRIMARY of table Tgupao .'t2' trx id 24467 lock_mode X locks rec but not gap思考：为什么需要（表级别的）意向锁？
第一个，我们有了表级别的锁，在InnoDB里面就可以支持更多粒度的锁。
第二个作用，当我们准备给一张表加上表锁的时候，必须先要去判断有没其他的事务锁定了其中了某些行。如果有的话，肯定不能加上表锁。那么这个时候我们就要去扫描整张表才能确定能不能成功加上一个表锁，如果数据量特别大，比如有上千万的数据的时候，加表锁的效率是不是很低?
但是我们引入了意向锁之后就不一样了。我只要判断这张表上面有没有意向锁,如果有，就直接返回失败。如果没有，就可以加锁成功。所以InnoDB里面的表锁，我们可以把它理解成一个标志。就像火车上厕所有没有人使用的灯，是用来提高加锁的效率的。
5.3 行锁的原理
锁锁住的是一行数据（ROW）吗？锁住的是一个字段（Column）吗？
5.3.1没有索引的表（假设锁住记录)
首先我们有三张表，一张没有索引的t1，一张有主键索引的t2，一张有唯一索引的t3。
我们先假设InnoDB的锁锁住了是一行数据或者一条记录。
现在我们在两个会话里面手工开启两个事务。
在第一个事务里面，我们通过 where id =1锁住第一行数据。
在第二个事务里面，我们尝试给id=3的这一行数据加锁,这个加锁的操作被阻塞了。我们再来操作一条不存在的数据，插入id=5。它也被阻塞了。
实际上这里整张表都被锁住了。所以，我们的第一个猜想被推翻了，InnoDB的锁锁住的应该不是Record。
5.3.2有主键索引的表
第一种情况，使用相同的id值去加锁，冲突;
使用不同的id 加锁，可以加锁成功。
那么，既然不是锁定一行数据，有没有可能是锁住了id的这个字段呢?
5.3.3 唯一索引（假设锁住字段)
在第一个事务里面，我们通过name字段去锁定值是4的这行数据。
在第二个事务里面，尝试获取一样的排它锁，肯定是失败的，这个不用怀疑。在这里我们怀疑InnoDB锁住的是字段，所以这次我换一个字段，用id=4去给这行数据加锁，又被阻塞了，说明锁住的是字段的这个推测也是错的，否则就不会出现第一个事务锁住了name，第二个字段锁住id 失败的情况。
既然锁住的不是record，也不是column,InnoDB里面锁住的到底是什么呢?
其实答案就是索引。InnoDB的行锁，就是通过锁住索引记录来实现的。
索引又是什么东西?为什么它可以被锁住?
从 information_schema.innodb_locks可以看到锁住的是索引。
还有两个问题没有解决:
1、为什么表里面没有索引的时候，锁住一行数据会导致锁表?或者说，如果锁住的是索引，一张表没有索引怎么办?
所以，一张表有没有可能没有索引?1)如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。
2）如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。
3）如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的 ROWID作为隐藏的聚集索引，它会随着行记录的写入而主键递增。
所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。
2、为什么通过唯一索引给数据行加锁，主键索引也会被锁住?
在InnoDB里面，当我们使用辅助索引的时候，它是怎么检索数据的?辅助索引的叶子节点存储的是什么内容?
在辅助索引里面,索引存储的是二级索引和主键的值。比如name=4,存储的是name的索引和主键id的值4。
而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引然后也锁定。
5.4 行锁的算法
有主键索引的表：
这些数据库里面存在的主键值，我们把它叫做Record，记录，那么这里我们就有4个Record.
根据主键，这些存在的Record隔开的数据不存在的区间，我们把它叫做Gap，间隙，它是一个左开右开的区间（不包括临界值）。（如果数据库中存在n个记录，那么存在n+1个间隙。）
间隙（Gap）连同它右边的记录(Record)，我们把它叫做临键的区间，它是一个左开右闭的区间。
【如果是字符形式，依然可以根据字符的ASCII码进行排序。】
5.4.1记录锁
当我们对于唯一性的索引(包括唯一索引和主键索引）使用等值查询，精准匹配到一条记录的时候，这个时候使用的就是记录锁。
比如where id = 1 4 7 10。
5.4.2间隙锁
当我们查询的记录不存在，没有命中任何一个record，无论是用等值查询还是范围查询的时候，它使用的都是间隙锁。
举个例子，where id >4 and id <7, where id = 6。
注意，间隙锁主要是阻塞插入insert。相同的间隙锁之间不冲突。
Gap Lock 只在RR中存在，如果要关闭间隙锁，就是把事务隔离级别设置成RC，并且把 innodb_locks_unsafe_for_binlog设置为ON。
这种情况下除了外键约束和唯一性检查会加间隙锁，其他情况都不会用间隙锁。
5.4.3临键锁
当我们使用了范围查询，不仅仅命中了Record记录，还包含了Gap 间隙，在这种情况下我们使用的就是临键锁，它是MySQL里面默认的行锁算法，相当于记录锁加上间隙锁。
比如我们使用>5 <9，它包含了记录不存在的区间，也包含了一个Record 7.
临键锁，锁住最后一个 key的下一个左开右闭的区间。
select * from t2 where id >5 and id <=7 for update;--锁住(4.7]和(7.10]
select * from t2 where id >8 and id <=I0 for update; --锁住(7,10]，(10,+o)注意：向右遍历时最后一个值不满足查询需求时，next-key lock 退化为间隙锁
5.4.4小结: InnoDB隔离级别的实现
5.4.4.1 Read Uncommited
RU隔离级别:不加锁。
5.4.4.2 Serializable
Serializable 所有的select语句都会被隐式的转化为select ... in share mode，会和update、 delete互斥。
这两个很好理解，主要是RR和RC的区别?
5.4.4.3 Repeatable Read
RR隔离级别下，普通的select使用快照读(snapshot read)，底层使用MVCC来实现。
加锁的select(select ... in share mode / select ... for update)以及更新操作update, delete等语句使用当前读(current read)，底层使用记录锁、或者间隙锁、临键锁。
间隙锁引入就是为了解决幻读问题。
5.4.4.4 Read Commited
RC隔离级别下，普通的select都是快照读，使用MVCC 实现。加锁的select都使用记录锁，因为没有Gap Lock。
除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重会键检查(duplicate-key checking)时会使用间隙锁封锁区间。
所以RC会出现幻读的问题。
RR和RC的主要区别在于：
RR中的MVCC在查询时只能看到第一次查询之前的数据；
而在RC的MVCC中，是能看到当前查询之前的数据。
5.4.5 事务隔离级别的选择
1、RR的间隙锁会导致锁定范围的扩大。
2、条件列未使用到索引，RR锁表，RC锁行。
3、RC的“半一致性”（semi-consistent）读可以增加update操作的并发性。