mysql学习（三）事务与锁

事务

• 事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。这里面有两个关键点，第一个，它是数据库最小的工作单元，是不可以再分的。第二个，它可能包含了一个或者一系列的DML 语句

事务的四大特性

• 第一个，原子性，Atomicity，也就是我们刚才说的不可再分，也就意味着我们对数据库的一系列的操作，要么都是成功，要么都是失败，不可能出现部分成功或者部分失败的情况。
• 第二个，一致性，consistent，指的是数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。比如主键必须是唯一的，字段长度符合要求。
• 第三个，隔离性，Isolation，我们有了事务的定义以后，在数据库里面会有很多的事务同时去操作我们的同一张表或者同一行数据，必然会产生一些并发或者干扰的操作，那么我们对隔离性的定义，就是这些很多个的事务，对表或者行的并发操作，应该是透明的，互相不干扰的。
• 最后一个叫做持久性，Durable，事务的持久性是什么意思呢？我们对数据库的任意的操作，增删改，只要事务提交成功，那么结果就是永久性的，不可能因为我们系统宕机或者重启了数据库的服务器，它又恢复到原来的状态了。这个就是事务的持久性。
  • 持久性是通过redo log 和double write 双写缓冲来实现的，我们操作数据的时候，会先写到内存的buffer pool 里面，同时记录redo log，如果在刷盘之前出现异常，在重启后就可以读取redo log 的内容，写入到磁盘，保证数据的持久性。

事务并发的问题

1. 会出现脏读的问题

   • 我们有两个事务，一个是Transaction A，一个是Transaction B，在第一个事务里面，它首先通过一个where id=1 的条件查询一条数据，返回name=Ada，age=16 的这条数据。然后第二个事务，它同样地是去操作id=1 的这行数据，它通过一个update的语句，把这行id=1 的数据的age 改成了18，但是注意，它没有提交。
   • 这个时候，在第一个事务里面，它再次去执行相同的查询操作，发现数据发生了变化，获取到的数据age 变成了18。那么，这种在一个事务里面，由于其他的时候修改了数据并且没有提交，而导致了前后两次读取数据不一致的情况，这种事务并发的问题，我们把它定义成脏读。
     

2. 不可重复读的问题，同样是两个事务，第一个事务通过id=1 查询到了一条数据。然后在第二个事务里面执行了一个update 操作，这里大家注意一下，执行了update 以后它通过一个commit 提交了修改。然后第一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况，就像这里，age 到底是等于16 还是18，那么这种事务并发带来的问题，这种问题被称之为不可重复读的问题
   

3. 幻读的问题，在第一个事务里面我们执行了一个范围查询，这个时候满足条件的数据只有一条。在第二个事务里面，它插入了一行数据，并且提交了。重点：插入了一行数据。在第一个事务里面再去查询的时候，它发现多了一行数据。这种情况，我们把它叫做幻读的问题
   

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

事务的隔离级别（SQL92 标准）

• 所以，就有很多的数据库专家联合制定了一个标准，也就是说建议数据库厂商都按照这个标准，提供一定的事务隔离级别，来解决事务并发的问题，这个就是SQL92 标准。
• 第一个隔离级别叫做：Read Uncommitted（未提交读），一个事务可以读取到其他事务未提交的数据，会出现脏读，所以叫做RU，它没有解决任何的问题。
• 第二个隔离级别叫做：Read Committed（已提交读），也就是一个事务只能读取到其他事务已提交的数据，不能读取到其他事务未提交的数据，它解决了脏读的问题，但是会出现不可重复读的问题。
• 第三个隔离级别叫做：Repeatable Read (可重复读)，它解决了不可重复读的问题，也就是在同一个事务里面多次读取同样的数据结果是一样的，但是在这个级别下，没有定义解决幻读的问题。
• 最后一个就是：Serializable（串行化），在这个隔离级别里面，所有的事务都是串行执行的，也就是对数据的操作需要排队，已经不存在事务的并发操作了，所以它解决了所有的问题。
• InnoDB 支持的四个隔离级别和SQL92 定义的基本一致，隔离级别越高，事务的并发度就越低。唯一的区别就在于，InnoDB 在RR 的级别就解决了幻读的问题。这个也是InnoDB 默认使用RR 作为事务隔离级别的原因，既保证了数据的一致性，又支持较高的并发度.

事务隔离的实现方案

• 第一种，我既然要保证前后两次读取数据一致，那么我读取数据的时候，锁定我要操作的数据，不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制Lock Based Concurrency Control（LBCC）。如果仅仅是基于锁来实现事务隔离，一个事务读取的时候不允许其他时候修改，那就意味着不支持并发的读写操作，而我们的大多数应用都是读多写少的，这样会极大地影响操作数据的效率。
• 第二种，如果要让一个事务前后两次读取的数据保持一致，那么我们可以在修改数据的时候给它建立一个备份或者叫快照，后面再来读取这个快照就行了。这种方案我们叫做多版本的并发控制Multi Version Concurrency Control（MVCC）。
  • MVCC 的核心思想是： 我可以查到在我这个事务开始之前已经存在的数据，即使它在后面被修改或者删除了。在我这个事务之后新增的数据，我是查不到的。

MVCC

• 这个快照什么时候创建？读取数据的时候，怎么保证能读取到这个快照而不是最新的数据？这个怎么实现呢？

• InnoDB 为每行记录都实现了两个隐藏字段：

  • DB_TRX_ID，6 字节：插入或更新行的最后一个事务的事务ID，事务编号是自动递增的（我们把它理解为创建版本号，在数据新增或者修改为新数据的时候，记录当前事务ID）。
  • DB_ROLL_PTR，7 字节：回滚指针（我们把它理解为删除版本号，数据被删除或记录为旧数据的时候，记录当前事务ID）。
  • 我们把这两个事务ID 理解为版本号。

• 下面我们来模拟一下：

• 首先第一个事务，初始化数据（检查初始数据），此时的数据，创建版本是当前事务ID，删除版本为空：
  
  

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

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

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

• 第四个事务，删除数据，删除了id=2 jack 这条记录：此时的数据，jack 的删除版本被记录为当前事务ID，4，其他数据不变：
  

• 在第二个事务中，执行第3 次查询：：只能查找创建时间小于等于当前事务ID 的数据，和删除时间大于当前事
  务ID 的行（或未删除）。也就是，在我事务开始之后删除的数据，所以jack 依然可以查出来。所以还是这两条数据。

• 第五个事务，执行更新操作，这个事务事务ID 是5：此时的数据，更新数据的时候，旧数据的删除版本被记录为当前事务ID 5（undo），产生了一条新数据，创建ID 为当前事务ID 5：
  

• 第二个事务，执行第4 次查询：因为更新后的数据penyuyan 创建版本大于2，代表是在事务之后增加的，查不出
  来。而旧数据qingshan 的删除版本大于2，代表是在事务之后删除的，可以查出来。

• 通过以上演示我们能看到，通过版本号的控制，无论其他事务是插入、修改、删除，第一个事务查询到的数据都没有变化。

• 在InnoDB 中，MVCC 是通过Undo log 实现的。Oracle、Postgres 等等其他数据库都有MVCC 的实现。需要注意，在InnoDB 中，MVCC 和锁是协同使用的，这两种方案并不是互斥的。

• 第一大类解决方案是锁，锁又是怎么实现读一致性的呢？

MySQL InnoDB 锁的基本类型

• InnoDB 里面既有行级别的锁，又有表级别的锁，我们先来分析一下这两种锁定粒度的一些差异。
  • 表锁，顾名思义，是锁住一张表；
  • 行锁就是锁住表里面的一行数据。
  • 锁定粒度，表锁肯定是大于行锁的。
  • 加锁效率：表锁大于行锁
  • 冲突概率：表锁大于行锁
• InnoDB 里面我们知道它既支持表锁又支持行锁，另一个常用的存储引擎MyISAM 支持什么粒度的锁？这是第一个问题。第二个就是InnoDB 已经支持行锁了，那么它也可以通过把表里面的每一行都锁住来实现表锁，为什么还要提供表锁呢？要搞清楚这个问题，我们就要来了解一下InnoDB 里面的基本的锁的模式（lock mode），这里面有两个行锁和两个表锁。

共享锁

• 第一个行级别的锁就是我们在官网看到的Shared Locks （共享锁），我们获取了一行数据的读锁以后，可以用来读取数据，所以它也叫做读锁，注意不要在加上了读锁以后去写数据，不然的话可能会出现死锁的情况。而且多个事务可以共享一把读锁。那怎么给一行数据加上读锁呢？我们可以用select …… lock in share mode; 的方式手工加上一把读锁。释放锁有两种方式，只要事务结束，锁就会自动事务，包括提交事务和结束事务。

排他锁

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

意向锁

• 意向锁是什么呢？我们好像从来没有听过，也从来没有使用过，其实他们是由数据库自己维护的。也就是说，当我们给一行数据加上共享锁之前，数据库会自动在这张表上面加一个意向共享锁。当我们给一行数据加上排他锁之前，数据库会自动在这张表上面加一个意向排他锁。反过来说：如果一张表上面至少有一个意向共享锁，说明有其他的事务给其中的某些数据行加上了共享锁。如果一张表上面至少有一个意向排他锁，说明有其他的事务给其中的某些数据行加上了排他锁。
• 那么这两个表级别的锁存在的意义是什么呢？第一个，我们有了表级别的锁，在 InnoDB 里面就可以支持更多粒度的锁。它的第二个作用，我们想一下，如果说没有意向锁的话，当我们准备给一张表加上表锁的时候，我们首先要做什么？是不是必须先要去判断有没其他的事务锁定了其中了某些行？如果有的话，肯定不能加上表锁。那么这个时候我们就要去扫描整张表才能确定能不能成功加上一个表锁，如果数据量特别大，比如有上千万的数据的时候，加表锁的效率是不是很低？
• 但是我们引入了意向锁之后就不一样了。我只要判断这张表上面有没有意向锁，如果有，就直接返回失败。如果没有，就可以加锁成功。所以InnoDB 里面的表锁，我们可以把它理解成一个标志。就像火车上厕所有没有人使用的灯，是用来提高加锁的效率的。

行锁的原理

• InnoDB 的行锁，就是通过锁住索引来实现的。
• 一张表的索引
  • 如果我们定义了主键(PRIMARY KEY)，那么InnoDB 会选择主键作为聚集索引。
  • 如果没有显式定义主键，则InnoDB 会选择第一个不包含有NULL 值的唯一索引作为主键索引。
  • 如果也没有这样的唯一索引，则InnoDB 会选择内置6 字节长的ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。
• 所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。
• 这就有个问题，为什么通过唯一索引给数据行加锁，主键索引也会被锁住？
  • 在辅助索引里面，索引存储的是二级索引和主键的值。比如name=4，存储的是name 的索引和主键id 的值4。
    而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然后也锁定。

锁的算法

• 这个我感觉我没有彻底理解透，可能写的不明不白的，直接推荐一个博客写的很清楚：临键锁如何实现幻读_什么是锁？深入分析解读MySQL锁，解决幻读问题