1.mysql数据库隔离级别

事务的四个特征：
事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ），这四个特性简称为 ACID 特性。
1 、原子性：事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做；
2 、一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态；
3 、隔离性：一个事务的执行不能其它事务干扰，即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰；
4 、持续性：也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

mysql四种隔离级别：
Read Uncommitted（读取未提交内容）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（读取提交内容）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

Repeatable Read（可重读）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制和next-key locks解决了该问题，但是实际中很少使用，因为一般的幻读问题是可以接受的。

Serializable（可串行化）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

事务的问题：
脏读：某个事务已经更新了一份数据，另一个事务在此时读取了同一份数据，但是由于某些原因，前一个事务回滚了，那么后一个事务读取的数据就会是不正确的。Read Uncommitted隔离级别就会产生这种问题。

不可重复读：在一个事务的两次查询的数据不一致，这可能是两次查询过程中间插入了一个事务更新了原有的数据。Read Uncommitted和Read Committed都会有这种问题。

幻读：在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。前面三种隔离级别都会有这种问题。

举例来说明：

CREATE TABLE `test` (
  `id` bigint(10) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(32) DEFAULT NULL COMMENT '姓名',
  `score` bigint(10) DEFAULT NULL COMMENT '分数',
  `time` datetime DEFAULT NULL COMMENT '考试时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=66 DEFAULT CHARSET=utf8mb4 COMMENT='测试表'

插入5条数据：

insert into `test`(`id`,`name`,`score`,`time`)
values(65,'小明',30,'2001-02-24 15:54:37');
insert into `test`(`id`,`name`,`score`,`time`)
values(58,'小刚',40,'2016-04-13 22:18:25');
insert into `test`(`id`,`name`,`score`,`time`)
values(56,'锦溪',50,'2013-06-09 14:07:45');
insert into `test`(`id`,`name`,`score`,`time`)
values(54,'满华',60,'2013-09-26 12:17:37');
insert into `test`(`id`,`name`,`score`,`time`)
values(50,'小五 ',70,'2018-10-01 23:54:15');

1.1 设置隔离级别为：Read Uncommitted
set session transaction isolation level read uncommitted
开两个客户端A和B(两个客户端必须首先都设置隔离级别)，A客户端执行：
begin;
insert into test(id,name,score,time)
values(70,'琪琪',30,'2001-02-24 15:54:37');
不提交事务

B客户端执行查询：SELECT * from test where id =70;
查询结果:

查询出来了A客户端事务中未提交的数据，如果此时A客户端事务进行回滚了，那么这个客户端查询出来的数据是错误的，就出现了脏读的问题。

1.2 设置隔离级别为：Read Committed
set session transaction isolation level read committed
开两个客户端A和B(两个客户端必须首先都设置隔离级别)，A客户端执行：
begin;
insert into test(id,name,score,time)
values(80,'小红',89,'2001-02-24 15:54:37');
不提交事务

B客户端执行查询:SELECT * from test where id =80;
查询结果为空

说明这个客户端无法查询到别的事务未提交的数据，把A客户端事务进行提交 commit，然后再进行查询，查询结果:

所以此隔离级别解决了脏读的问题，但是无法解决可重读的问题，为了验证也是开两个客户端A和B(两个客户端必须首先都设置隔离级别)，A客户端执行：
begin;
update test set name ='丁丁' where id=50;

B客户端执行:
BEGIN;
SELECT * from test where id =50;
此时B客户端返回的数据为：

B事务暂时也不提交，然后将A事务进行提交commit，然后在B事务中再次执行查询操作:SELECT * from test where id =50;
查询结果为：

同一个事务中查询的数据已经不一致了，所以产生了不可重复读的问题，为了解决这个问题，引入下面的隔离级别。

1.3 设置隔离级别为：Repeatable Read
set session transaction isolation level repeatable read
开两个客户端A和B(两个客户端必须首先都设置隔离级别)，A客户端执行：
begin;
update test set name ='江滔' where id=56;
不要提交事务

B客户端执行:
BEGIN;
SELECT * from test where id =56;
也不要提交事务，查询出来的数据为：

然后将A事务提交commit，再在B事务重新执行SELECT * from test where id =56;查询出来的数据还是和上面的一致:

所以在一个事务中，两次查询出来的结果是一致的，不管外面的事务有没有对其进行改变。但是这种隔离级别会出现幻读，举例说明：
A和B客户端，分别开启事务，A执行：
begin;
insert into test(id,name,score,time)
values(101,'小程',100,'2001-02-24 15:54:37');
不提交事务
B执行:
BEGIN;
SELECT * from test where id = 101
这个时候B肯定是查询不到数据的，因为A未提交，将A提交后，根据可重复读的含义，B应该还是查询不到的，但是可惜，这个时候B再执行一次查询后输出结果：

这种问题叫幻读，对新插入的数据，这种隔离级别没法解决的，但是MYSQL提供了解决方案，本文后续会讲到，最暴力的方式是采取下面最后一种隔离级别。

1.4 设置隔离级别为：serializable
set session transaction isolation level serializable;
这种隔离级别一般不会用，因为会导致并发和吞吐量严重下降，不适合互联网项目，但是它能解决上面所说的所有问题，包括脏读，不可重复读，幻写。

2. 锁

排他锁和共享锁（类似于java中的读锁和写锁）
排他锁是独占锁，禁止其他事务获取锁（包括排他锁和独占锁），如果其他事务不用获取锁是可以的；共享锁是说多个事务可以同时获得此锁，但是一旦获取此锁，别的事务就不能获取排他锁，举例说明：
排他锁语法：select * from test where id=? for update;
共享锁语法：select * from test where id=? lock in share mode;
为了验证，举例子说明：

2.1 验证独占锁例子
开启A和B客户端
A客户端执行
begin;
select * from test where id=56 for update;
不提交事务，然后B客户端执行：
select * from test where id=56;
此时返回了正确的数据，客户端没有阻塞，因为此语句不会获取锁，排他锁是禁止其他事务获取锁，但是对于不用获取锁的语句是不会禁止的。
如果B客户端执行：

客户端阻塞了，然后此时将A事务提交，阻塞才会停止。

2.2 验证共享锁的例子
开启A和B客户端
A客户端执行
begin;
select * from test where id=56 lock in share mode;
不提交事务，然后B客户端执行：
select * from test where id=56 lock in share mode;
返回了正常的数据：

如果B客户端执行：

B客户端阻塞注，必须先将A事务提交
所以说明了共享锁是允许其他事务获取共享锁，但是禁止其他事务获取独占锁。

参考文章：
https://www.cnblogs.com/mr-wuxiansheng/p/7044733.html
https://www.cnblogs.com/jian-gao/p/10795407.html
https://jingyan.baidu.com/article/f25ef254891845482c1b8215.html
https://www.cnblogs.com/liyus/p/10556563.html