MySQL事务
mysql的事务就是由一个或多个sql语句组成的一个整体，里面的内容要么都执行成功，要么都不成功。
在mysql中，常见的存储引擎有innodb、myisam，memory等。其中innodb支持事务(transaction)，而myisam，memory等不支持事务。
事务的四个特性(ACID)
原子性（Atomicity）：指事务是一个不可分割的最小工作单位，事务中的操作只有都发生和都不发生两种情况。
一致性（Consistency）：一致性是指数据处于一种语义上的有意义且正确的状态。一致性是对数据可见性的约束，保证在一个事务中的多次操作的数据中间状态对其他事务不可见的。因为这些中间状态，是一个过渡状态，与事务的开始状态和事务的结束状态是不一致的。
隔离性（Isolation）：一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
持久性（Durability）：一个事务一旦提交成功，它对数据库中数据的改变将是永久性的，接下来的其他操作或故障不应对其有任何影响。
事务的分类
事务分为隐式事务和显式事务两种。默认情况下我们的DML语句（insert、update、delete）就是隐式事务。
1: 隐式事务：该事务没有明显的开启和结束标记，它们都具有自动提交事务的功能
2: 显示事务：该事务具有明显的开启和结束标记；使用显式事务的前提是你得先把自动提交事务的功能给禁用。禁用自动提交功能就是设置autocommit变量值为0（0:禁用 1:开启）, 使用 start transaction 和 commit 和 rollback 的组合来执行事务
事务隔离级别介绍
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 未提交读（Read uncommitted） | 可能 | 可能 | 可能 |
| 已提交读（Read committed） | 不可能 | 可能 | 可能 |
| 可重复读（Repeatable read） | 不可能 | 不可能 | 可能 |
| 可串行化（Serializable ） | 不可能 | 不可能 | 不可能 |
- 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
- 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
- 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读，但是innoDB解决了幻读
- 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞, 所有事物串行,最高隔离级别，性能最差
mysql用下列语句查询全局和会话事务隔离级别
SELECT @@global.tx_isolation;
SELECT @@session.tx_isolation;
SELECT @@tx_isolation;
在RR级别中，我们解决了不可重复读的问题，即在这种隔离级别下，在一个事务中我们能够保证能够获取到一样的数据（即使已经有其他事务修改了我们的数据），但是无法避免幻读。
幻读简单的解释就是在数据有新增的时候，也无法保证两次得到的数据不一致，但是不同数据库对不同的RR级别有不同的实现，有时候或加上间隙锁来避免幻读。
innodb引擎解决了幻读的问题，基于MVCC（多版本并发控制) , 在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。
在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。
存在的问题？
在RR模型,我们虽然避免了幻读，但是存在一个问题，我们得到的数据不是数据中实时的数据，如果是对实时数据比较敏感的业务，这是不现实的。
对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。很显然，在MVCC中：
- 快照读：就是select
- select * from table ….;
- 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。
- select * from table where ? lock in share mode;
- select * from table where ? for update;
- insert;
- update ;
- delete;
事务的隔离级别实际上都是定义了当前读的级别，MySQL为了减少锁处理（包括等待其它锁）的时间，提升并发能力，引入了快照读的概念，使得select不用加锁。
而update、insert这些“当前读”，就需要另外的模块来解决了。
比如，我们有以下的订单业务场景，我们队一个商品下单的操作，我们得首先检查这个订单的数量还剩多少，然后下单。
事务1:
select num from t_goods where id=1;
update t_goods set num=num-$mynum where id=1;
事务2：
select num from t_goods where id=1;
update t_goods set num=num-$mynum where id=1;
假设这个时候数量只有1，我们下单也是只有1.如果在并发的情况下，事务1查询到还有一单准备下单，但是这个时候事务2已经提交了。
订单变成0.这个事务1在执行update，就会造成事故。
- 方法1(悲观锁)：就是利用for update对着个商品加锁，事务完成之后释放锁。切记where条件的有索引，否则会锁全表。
- 方法2(乐观锁)：给数据库表加上个version字段。然后SQL改写:
select num,version from t_goods where id=1;
update t_goods set num=num-1,version=verison+1 where id=1 and version=${version}
InnoDB 三种行锁
https://www.jianshu.com/p/478bc84a7721
- Record Lock（记录锁）：锁住某一行记录 ， LOCK_MODE 为
X, REC_NOT_GAP - Gap Lock（间隙锁）：锁住一段左开右开的区间 , LOCK_MODE 为
X, GAP
当对已存在的行进行锁定时(主键)，mysql就只有行锁, 也就是记录锁。
当对未存在的行进行锁的时候(即使条件为主键)，mysql会锁住一段范围（即gap锁），其锁范围为： (无穷小或小于表中锁住id的最大值，无穷大或大于表中锁住id的最小值)
如果表中目前有已有的id为18，那么就锁住（18，无穷大）； 如果表中目前已有的id为（11 ， 30），那么就锁住（11，30）；
- Next-key Lock（临键锁）：锁住一段左开右闭的区间 , LOCK_MODE 为
X
Next-key锁是记录锁和间隙锁的组合，它指的是加在某条记录以及这条记录前面间隙上的锁。
也可以理解为一种特殊的间隙锁。通过临建锁可以解决幻读的问题。 每个数据行上的非唯一索引列上都会存在一把临键锁，当某个事务持有该数据行的临键锁时，会锁住一段左开右闭区间的数据。需要强调的一点是，InnoDB 中行级锁是基于索引实现的，临键锁只与非唯一索引列有关，在唯一索引列（包括主键列）上不存在临键锁。
哪些语句上面会加行锁？
1）对于常见的 DML 语句（如 UPDATE、DELETE 和 INSERT ），InnoDB 会自动给相应的记录行加写锁
2）默认情况下对于普通 SELECT 语句，InnoDB 不会加任何锁，但是在 Serializable 隔离级别下会加行级读锁
上面两种是隐式锁定，InnoDB 也支持通过特定的语句进行显式锁定：
3）SELECT * FROM table_name WHERE ... FOR UPDATE，加行级写锁
4）SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE，加行级读锁
前置知识就不过多介绍了，在学习具体行锁加锁规则之前，小伙伴们需要记住加锁规则的两条核心：
1）查找过程中访问到的对象才会加锁
这句话该怎么理解？比如有主键 id 为
1 2 3 4 5 ... 10的10 条记录，我们要找到id = 7的记录。注意，查找并不是从第一行开始一行一行地进行遍历，而是根据 B+ 树的特性进行二分查找，所以一般存储引擎只会访问到要找的记录行（
id = 7）的相邻区间
2）加锁的基本单位是 Next-key Lock
下面结合实例帮助大伙分析一条 SQL 语句上面究竟被 InnoDB 自动加上了多少个锁
假设有这么一张 user 表，id 为主键（唯一索引），a 是普通索引（非唯一索引），b 都是普通的列，其上没有任何索引：
| id (唯一索引) | a (非唯一索引) | b |
|---|---|---|
| 10 | 4 | Alice |
| 15 | 8 | Bob |
| 20 | 16 | Cilly |
| 25 | 32 | Druid |
| 30 | 64 | Erik |
案例 1：唯一索引等值查询
当我们用唯一索引进行等值查询的时候，根据查询的记录是否存在，加锁的规则会有所不同：
- 当查询的记录是存在的，Next-key Lock 会退化成记录锁
- 当查询的记录是不存在的，Next-key Lock 会退化成间隙锁
查询的记录存在
先来看个查询的记录存在的案例：
select * from user where id = 25 for update;
结合加锁的两条核心：查找过程中访问到的对象才会加锁 + 加锁的基本单位是 Next-key Lock（左开右闭），我们可以分析出，这条语句的加锁范围是 (20, 25]
不过，由于这个唯一索引等值查询的记录 id = 25 是存在的，因此，Next-key Lock 会退化成记录锁，因此最终的加锁范围是 id = 25 这一行
查询的记录不存在
再来看查询的记录不存在的案例：
select * from user where id = 22 for update;
这里为什么是 (20，25] 而不是 (20, 22]，因为 id = 22 的记录不存在呀，InnoDB 先找到 id = 20 的记录，发现不匹配，于是继续往下找，发现 id = 25，
因此，id = 25 的这一行被扫描到了，所以整体的加锁范围是 (20, 25]
由于这个唯一索引等值查询的记录 id = 22 是不存在的，因此，Next-key Lock 会退化成间隙锁，因此最终在主键 id 上的加锁范围是 Gap Lock (20, 25)
案例 2：唯一索引范围查询
唯一索引范围查询的规则和等值查询的规则一样，只有一个区别，就是唯一索引的范围查询需要一直向右遍历到第一个不满足条件的记录，下面结合案例来分析：
select * from user where id >= 20 and id < 22 for update;
先来看语句查询条件的前半部分 id >= 20，因此，这条语句最开始要找的第一行是 id = 20，结合加锁的两个核心，需要加上 Next-key Lock (15,20]。
又由于 id 是唯一索引，且 id = 20 的这行记录是存在的，因此会退化成记录锁，也就是只会对 id = 20 这一行加锁。
再来看语句查询条件的后半部分 id < 22，由于是范围查找，就会继续往后找第一个不满足条件的记录，也就是会找到 id = 25 这一行停下来，
然后加 Next-key Lock (20, 25]，重点来了，但由于 id = 25 不满足 id < 22，因此会退化成间隙锁，加锁范围变为 (20, 25)。
所以，上述语句在主键 id 上的最终的加锁范围是 Record Lock id = 20 以及 Gap Lock (20, 25)
案例 3：非唯一索引等值查询
当我们用非唯一索引进行等值查询的时候，根据查询的记录是否存在，加锁的规则会有所不同：
-
当查询的记录是存在的，除了会加 Next-key Lock 外，还会额外加间隙锁（规则是向下遍历到第一个不符合条件的值才能停止），也就是会加两把锁
就是要查找记录的左区间加 Next-key Lock，右区间加 Gap lock
-
当查询的记录是不存在的，Next-key Lock 会退化成间隙锁（这个规则和唯一索引的等值查询是一样的）
查询的记录存在
先来看个查询的记录存在的案例：
select * from user where a = 16 for update;
结合加锁的两条核心，这条语句首先会对普通索引 a 加上 Next-key Lock，范围是 (8,16]
又因为是非唯一索引等值查询，且查询的记录 a= 16 是存在的，所以还会加上间隙锁，规则是向下遍历到第一个不符合条件的值才能停止，因此间隙锁的范围是 (16,32)
所以，上述语句在普通索引 a 上的最终加锁范围是 Next-key Lock (8,16] 以及 Gap Lock (16,32)
查询的记录不存在
再来看查询的记录不存在的案例：
select * from user where a = 18 for update;
结合加锁的两条核心，这条语句首先会对普通索引 a 加上 Next-key Lock，范围是 (16,32]
但是由于查询的记录 a = 18 是不存在的，因此 Next-key Lock 会退化为间隙锁，即最终在普通索引 a 上的加锁范围是 (16,32)。
案例 4：非唯一索引范围查询
范围查询和等值查询的区别在上面唯一索引章节已经介绍过了，就是范围查询需要一直向右遍历到第一个不满足条件的记录，
和唯一索引范围查询不同的是，非唯一索引的范围查询并不会退化成 Record Lock 或者 Gap Lock。
select * from user where a >= 16 and a < 18 for update;
先来看语句查询条件的前半部分 a >= 16，因此，这条语句最开始要找的第一行是 a = 16，结合加锁的两个核心，需要加上 Next-key Lock (8,16]。
虽然非唯一索引 a = 16 的这行记录是存在的，但此时并不会像唯一索引那样退化成记录锁。
再来看语句查询条件的后半部分 a < 18，由于是范围查找，就会继续往后找第一个不满足条件的记录，也就是会找到 id = 32 这一行停下来，
然后加 Next-key Lock (16, 32]。虽然 id = 32 不满足 id < 18，但此时并不会向唯一索引那样退化成间隙锁。
所以，上述语句在普通索引 a 上的最终的加锁范围是 Next-key Lock (8, 16] 和 (16, 32]，也就是 (8, 32]。
浙公网安备 33010602011771号