四、MySQL事务与锁机制

文章非原创，属于对以往学习到的知识的归纳总结，文中可能存在大段截取其他文章的片段，博客属于自我学习的笔记总结会持续更新。。。

一、事务基本概述
平时，我们执行增删改的时候，无非就是从磁盘中加载数据页到缓冲池中，对缓冲页数据进行更新，同时记录下来undo log 回滚日志，和redo log 重做日志，分别应对事务提交之后事务回滚，以及mysql挂了恢复数据的场景。
我们的业务系统去访问数据库而言，他往往都是多个线程并发执行多个事务的，对于数据库而言，他会有多个事务同时执行，每个事务都会执行各种增删改查的语句，把磁盘上的数据页加载到buffer pool的缓存页里来，然后更新缓存页，记录redo log和undo log，最终提交事务或者是回滚事务。同时可能这多个事务还会同时更新和查询同一条数据

事务及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。

• 原子性(Atomicity) ：事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。
• 一致性(Consistent) ：在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性。
• 隔离性(Isolation) ：数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
• 持久性(Durable) ：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

如果多个事务同时操作一条数据，会涉及到脏写、脏读、不可重复读、幻读，四种问题。

• 脏写
  有两个事务，事务A和事务B同时在更新一条数据，事务A先把他更新为A值，事务B紧接着就把他更新为B值，此时事务A的undo log日志大概就是：更新之前这行数据的值为NULL，主键为XX。此时事务B更新完了数据的值为B，结果此时事务A突然回滚了，那么就会用他的undo log日志去回滚。此时事务A一回滚，直接就会把那行数据的值更新回之前的NULL值，导致事务B更新的值也一并没有了，对于事务B看到的场景，就是自己明明更新了，结果值却没了，这就是脏写！
  本质就是事务B去修改了事务A修改过的值，但是此时事务A还没提交，所以事务A随时会回滚，导致事务B修改的值也没了，这就是脏写的定义。

• 脏读
  事务A更新了一条数据为A值，还没有提交事务。事务B查询到事务A修改的值，此时事务A回滚，数据变回原来的NULL,此时事务B再次查询该条数据，就读不到事务A刚才修改的数据了。
  脏读的本质是事务B读取到了事务A还没有提交的数据。

• 不可重复读
  事务A读取一条数据（假定为A），事务B将该条数据修改为B 并提交了事务，此时事务A（还没有提交）再次读取该条数据时，就变成了B。如果此时事务C又对该条数据进行了更新为值C，此时事务A再次读取的时候值又变成了C。在事务A 执行期间，多次查询数据，都是同样的一个A值，他希望这个A值是他重复读取的时候一直可以读到的！但是现在是不可重复读的。

• 幻读
  事务A 查询第一次查询一组数据为10个，事务B 新增了一条数据，并提交事务，事务A再次查询时 查出11条数据，事务C新增一条数据，事务A第三次查询，查到12条数据。事务A多次查询都会发现查到了一些之前没看到过的数据。这就是幻读！

事务的隔离级别
read uncommitted（读未提交），read committed（读已提交），repeatable read（可重复读），serializable（串行化）

• 读未提交
  最低隔离级别 不允许发生脏写
• 读已提交（RC）
  避免出现脏读，无法避免重复读与幻读
• 可重复读（RR）
  能避免脏读，不可重复读，但还是会出现幻读，Mysql 默认的隔离级别
• 串行化
  所有事务串行化执行，不会出现脏读 不可重复读 幻读问题。

常看当前数据库的事务隔离级别: show variables like 'tx_isolation';

要修改MySQL的默认事务隔离级别，是下面的命令，可以设置级别为不同的level，level的值可以是REPEATABLE READ，READ COMMITTED，READ UNCOMMITTED，SERIALIZABLE几种级别。

具体命令： SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL level;

如用Spring里的@Transactional注解来做事务这块，在@Transactional注解里是有一个isolation参数的，里面是可以设置事务隔离级别的，具体的设置方式如下：@Transactional(isolation=Isolation.DEFAULT)，然后默认的就是DEFAULT值，这个就是MySQL默认支持什么隔离级别就是什么隔离级别。也可以改成Isolation.READ_COMMITTED，Isolation.REPEATABLE_READ，Isolation.SERIALIZABLE几个级别，都是可以的。

二、事务隔离级别实现的原理

1.undo log版本链
简单来说呢，我们每条数据其实都有两个隐藏字段，一个是trx_id，一个是roll_pointer，这个trx_id就是最近一次更新这条数据的事务id，roll_pointer就是指向了你更新这个事务之前生成的undo log。
举个例子，现在假设有一个事务A（id=50），插入了一条数据，那么此时这条数据的隐藏字段以及指向的undo log如下图所示，插入的这条数据的值是值A，因为事务A的id是50，所以这条数据的txr_id就是50，roll_pointer指向一个空的undo log，因为之前这条数据是没有的。

接着假设有一个事务B跑来修改了一下这条数据，把值改成了值B，事务B的id是58，那么此时更新之前会生成一个undo log记录之前的值，然后会让roll_pointer指向这个实际的undo log回滚日志，如下图所示。

接着假设事务C又来修改了一下这个值为值C，他的事务id是69，此时会把数据行里的txr_id改成69，然后生成一条undo log，记录之前事务B修改的那个值

多个事务串行执行的时候，每个人修改了一行数据，都会更新隐藏字段txr_id和roll_pointer，同时之前多个数据快照对应的undo log，会通过roll_pinter指针串联起来，形成一个重要的版本链！

2.基于undo log多版本链条实现的ReadView机制

每个事务执行的时候都会生成一个ReadView，里面比较关键的元素有4个

• 一个是m_ids，这个就是说此时有哪些事务在MySQL里执行还没提交的；
• 一个是min_trx_id，就是m_ids里最小的值；
• 一个是max_trx_id，这是说mysql下一个要生成的事务id，就是最大事务id；
• 一个是creator_trx_id，就是你这个事务的id

假设原来数据库里就有一行数据，事务id是32，是初始值，如下图所示。

接着呢，此时两个事务并发过来执行了，一个是事务A（id=45），一个是事务B（id=59），事务B是要去更新这行数据的，事务A是要去读取这行数据的值的。
现在事务A直接开启一个ReadView，这个ReadView里的m_ids就包含了事务A和事务B的两个id，45和59，然后min_trx_id就是45，max_trx_id就是60，creator_trx_id就是45，是事务A自己。
这个时候事务A第一次查询这行数据，会走一个判断，就是判断一下当前这行数据的txr_id是否小于ReadView中的min_trx_id，此时发现txr_id=32，是小于ReadView里的min_trx_id就是45的，说明你事务开启之前，修改这行数据的事务早就提交了，所以此时可以查到这行数据，如下图所示。

接着事务B把这行数据的值修改为了值B，然后这行数据的txr_id设置为59，同时roll_pointer指向了修改之前生成的一个undo log，事务B提交，如下图所示。

这个时候事务A再次查询，此时查询的时候，会发现一个问题，那就是此时数据行里的txr_id=59，那么这个txr_id是大于ReadView里的min_txr_id(45)，同时小于ReadView里的max_trx_id（60）的，说明更新这条数据的事务，很可能就跟自己差不多同时开启的，于是会看一下这个txr_id=59，是否在ReadView的m_ids列表里？果然，在ReadView的m_ids列表里，有45和59两个事务id，直接证实了，这个修改数据的事务是跟自己同一时段并发执行然后提交的，所以对这行数据是不能查询的！如下图所示

那么既然这行数据不能查询，那查什么呢？简单，顺着这条数据的roll_pointer顺着undo log日志链条往下找，就会找到最近的一条undo log，trx_id是32，此时发现trx_id=32，是小于ReadView里的min_trx_id（45）的，说明这个undo log版本必然是在事务A开启之前就执行且提交的。好了，那么就查询最近的那个undo log里的值好了，这就是undo log多版本链条的作用，他可以保存一个快照链条，让你可以读到之前的快照值，如下图。

接着假设事务A自己更新了这行数据的值，改成值A，trx_id修改为45，同时保存之前事务B修改的值的快照。此时事务A再来查询这条数据的值，会发现这个trx_id=45，居然跟自己的ReadView里的creator_trx_id（45）是一样，说明这行数据就是自己修改的。如下图。

接着在事务A执行的过程中，突然开启了一个事务C，这个事务的id是78，然后更新数据的值为C提交。这时事务A再去查询，发现当前数据的trx_id=78，大于了自己的ReadView中的max_trx_id（60），此时说明是这个事务A开启之后，然后有一个事务更新了数据，自己是不能看到的！如下图

此时就会顺着undo log多版本链条往下找，自然先找到值A自己之前修改的过的那个版本，因为那个trx_id=45跟自己的ReadView里的creator_trx_id是一样的，所以此时直接读取自己之前修改的那个版本。通过undo log多版本链条与开启事务时创建的ReadView，通过ReadView的判断机制，可以保证你只能读到你事务开启前，别的提交事务更新的值，还有就是你自己事务更新的值。假如说是你事务开启之前，就有别的事务正在运行，然后你事务开启之后 ，别的事务更新了值，你是绝对读不到的！或者是你事务开启之后，比你晚开启的事务更新了值，也是读不到的！

3.RC与RR隔离级别下ReadView是如何运行的

• RC(Read Committed 读已提交)
  当一个事务设置处于RC隔离级别的时候，每次发起查询，都重新生成一个ReadView。
  先假设我们的数据库里有一行数据，是事务id=50之前就插入进去的，现在有两个事务，事务A（id=60），事务B（id=70）。现在事务B发起了一次update操作，把这条数据的值修改为了值B，此时数据的trx_id变为事务B的id=70，同时会生成一条undo log，由roll_pointer来指向原初始值，这时事务A发起一次查询操作，生成一个ReadView，ReadView里的min_trx_id=60，max_trx_id=71，creator_trx_id=60。事务A发现当前这条数据的trx_id是70。属于ReadView的事务id范围之间，说明是他生成ReadView之前就有这个活跃的事务，是这个事务修改了这条数据的值，但是此时这个事务B还没提交，根据ReadView的机制，此时事务A是无法查到事务B修改的值B的。接着事物A就顺着undo log版本链条往下查找，就会找到一个原始值，发现他的trx_id是50，小于当前ReadView里的min_trx_id，说明是他生成ReadView之前，就有一个事务插入了这个值并且早就提交了，因此可以查到这个原始值，流程分析如下图：
  
  接着，假设事务B此时提交了，那么按照RC隔离级别的定义，事务B此时一旦提交了，说明事务A下次再查询，就可以读到事务B修改过的值了，因为事务B提交了。事务A下次发起查询，会再次生成一个ReadView。因为数据库内活跃的事务只有事务A了，所以min_trx_id是60，mac_trx_id是71，m_ids这个活跃事务列表里，只有一个60。此时事务A基于这个ReadView去查询，会发现trx_id=70的这条数据，虽然在ReadView的min_trx_id和max_trx_id范围之间，但是此时并不在m_ids列表内，说明事务B在生成本次ReadView之前就已经提交了。那么既然在生成本次ReadView之前，事务B就已经提交了，就说明这次你查询就可以查到事务B修改过的这个值了，此时事务A就会查到值B
  
  综上所述 RC隔离级别的实现，就是每次查询都会生成一个新的ReadView,查询数据的时候将事物的trx_id 与m_ids 做对比，如果在m_ids中不存在就说明事物已经提交对应的该条数据就是可以被查询的。事实上基于undo log多版本链条以及ReadView机制实现的多事务并发执行的RC隔离级别、RR隔离级别，就是数据库的MVCC多版本并发控制机制。

• RR（不可重复读）
  假设有一条数据是事务id=50的一个事务插入的，同时此时有事务A和事务B同时在运行，事务A的id是60，事务B的id是70这个时候，事务A发起了一个查询，他就是第一次查询生成一个ReadView，此时ReadView里的creator_trx_id是60，min_trx_id是60，max_trx_id是71，m_ids是[60, 70]。这个时候事务A基于这个ReadView去查这条数据，会发现这条数据的trx_id为50，是小于ReadView里的min_trx_id的，说明他发起查询之前，早就有事务插入这条数据还提交了，所以此时可以查到这条原始值的。
  
  接着事务B更新了这条数据，此时trx_id为70，同时生成一个undo log，而且事务B此时提交了，如下图所示。
  
  因为ReadView一旦生成了就不会改变了，这个时候虽然事务B已经结束了，但是事务A的ReadView里，还是会有60和70两个事务id接着此时事务A去查询这条数据的值，他会惊讶的发现此时数据的trx_id是70了，70一方面是在ReadView的min_trx_id和max_trx_id的范围区间的，同时还在m_ids列表中。说明起码是事务A开启查询的时候，id为70的这个事务B还是在运行的，就算事务B更新了这条数据，此时事务A也是不能查询到事务B更新的这个值的，因此这个时候继续顺着指针往历史版本链条上去找，如下图。
  
  接着事务A顺着指针找到下面一条数据，trx_id为50，是小于ReadView的min_trx_id的，说明在他开启查询之前，就已经提交了这个事务了，所以事务A是可以查询到这个值的，此时事务A查到的是原始值。
  事务A多次读同一个数据，每次读到的都是一样的值，除非是他自己修改了值，否则读到的一直会一样的值。不管别的事务如何修改数据，事务A的ReadView始终是不变的，他基于这个ReadView始终看到的值是一样的！

幻读的问题是如何解决的呢。假设现在事务A先用select * from x where id>10来查询，此时可能查到的就是一条数据，而且读到的是这条数据的原始值的那个版本。现在有一个事务C插入了一条数据，然后提交了。接着事务A再次查询，此时会发现符合条件的有2条数据，一条是原始值那个数据，一条是事务C插入的那条数据，但是事务C插入的那条数据的trx_id是80，这个80是大于自己的ReadView的max_trx_id的，说明是自己发起查询之后，这个事务才启动的，所以此时这条数据是不能查询的。因此事务A本次查询，还是只能查到原始值一条数据。所以事务A根本不会发生幻读，他根据条件范围查询的时候，每次读到的数据都是一样的，不会读到人家插入进去的数据，这都是依托ReadView机制实现的！

三、锁机制

事物隔离处理的是多个事物并发读写一批数据的协调问题。锁处理的是多个事物并发更新一行数据的情况，在没有锁的情况下，多个事物同时更新同一条数据，其中任意事物回滚都会导致其他事物的更新操作失效，这就是脏写啊。因此锁的最基本使用其实就是杜绝脏写的发生。基本的逻辑在于使用锁将多个事物操作同一条数据的时候串行化，假如事物A 事物B 更新同一条数据，此时A先获得更新数据的权限，此时这个事务就会创建一个锁，里面包含了自己的trx_id和等待状态，然后把锁跟这行数据关联在一起。如图

此时事物B也想更新该条数据，但发现该条数据被加锁了，因此事物B也创建一个锁，来关联该条数据已存在的锁，进入等待状态:

事物A更新数据并提交后，发现后面有锁等待便将事物B的等待状态修改为false，唤醒事物B。以上就是锁机制的基本逻辑，那事物A B加的锁具体是什么呢？

1.锁分类

• 从性能上分为乐观锁(用版本对比来实现)和悲观锁
• 从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)
  读锁（共享锁，S锁(Shared)）：针对同一份数据，多个读操作可以同时进行而不会互相影响
  写锁（排它锁，X锁(eXclusive)）：当前写操作没有完成前，它会阻断其他写锁和读锁
• 从对数据操作的粒度分，分为全局锁、表锁和行锁
  因此上文中的事物A B 加的其实是写锁（排它锁/独占锁、Exclude）也是行锁。生成了独占锁其他事物还要更新该条数据的时候就需要排队等待，但是如果其他的事物要查询该条数据的时候，默认情况下就不需要再加锁了，直接默认开启MVCC机制。由此可见对一行数据的读和写两个操作默认是不会加锁互斥的就避免了频繁的加锁互斥。

全局锁：
顾名思义，全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。
全局锁的典型使用场景是，做全库逻辑备份。

表锁：很鸡肋！！
LOCK TABLES xxx READ：这是加表级共享锁
LOCK TABLES xxx WRITE：这是加表级独占锁

行锁：
每次操作锁住一行数据。开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最高。InnoDB在执行查询语句SELECT时，因为有mvcc机制不会加锁。但是update、insert、delete操作会加行锁。读锁会阻塞写，但是不会阻塞读。而写锁则会把读和写都阻塞。

无索引行锁会升级为表锁:
锁主要是加在索引上，如果对非索引字段更新，行锁可能会变表锁
session1 执行：update account set balance = 800 where name = 'lilei';
session2 对该表任一行操作都会阻塞住
InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。
锁定某一行还可以用lock in share mode(共享锁) 和for update(排它锁)，例如：select * from test_innodb_lock where a = 2 for update; 这样其他session只能读这行数据，修改则会被阻塞，直到锁定行的session提交

行锁分析
通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

show status like'innodb_row_lock%';

对各个状态量的说明如下：
Innodb_row_lock_current_waits: 当前正在等待锁定的数量
Innodb_row_lock_time: 从系统启动到现在锁定总时间长度
Innodb_row_lock_time_avg: 每次等待所花平均时间
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花时间
Innodb_row_lock_waits:系统启动后到现在总共等待的次数
尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手制定优化计划。

锁优化建议
尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
合理设计索引，尽量缩小锁的范围
尽可能减少检索条件范围，避免间隙锁
尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行
尽可能低级别事务隔离

下一篇介绍：五、MySQL索引
（笔记我放在为知笔记（爸爸请打钱 【狗头】）上的，上传后，我再回来加个链接。机（ma）智(de)如(zhi)我(zhang)！！）