mysql 丢失更新1和2、脏读、不可重复读和幻读 事务隔离级别 悲观锁 乐观锁
事务是现代关系型数据库的核心之一。在多个事务并发操作数据库（多线程、网络并发等）的时候，如果没有有效的避免机制，就会出现以下几种问题：
（
第一类丢失更新
A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来：
|
时间 |
取款事务A |
转账事务B |
|
T1 |
开始事务 |
|
|
T2 |
|
开始事务 |
|
T3 |
查询账户余额为1000元 |
|
|
T4 |
|
查询账户余额为1000元 |
|
T5 |
|
汇入100元把余额改为1100元 |
|
T6 |
|
提交事务 |
|
T7 |
取出100元把余额改为900元 |
|
|
T8 |
撤销事务 |
|
|
T9 |
余额恢复为1000 元（丢失更新） |
|
A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。
SQL92没有定义这种现象，标准定义的所有隔离界别都不允许第一类丢失更新发生。
第二类丢失更新
A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失：
|
时间 |
转账事务A |
取款事务B |
|
T1 |
|
开始事务 |
|
T2 |
开始事务 |
|
|
T3 |
|
查询账户余额为1000元 |
|
T4 |
查询账户余额为1000元 |
|
|
T5 |
|
取出100元把余额改为900元 |
|
T6 |
|
提交事务 |
|
T7 |
汇入100元 |
|
|
T8 |
提交事务 |
|
|
T9 |
把余额改为1100 元（丢失更新） |
|
上面的例子里由于支票转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。
）
第一类丢失更新（Lost Update）
在完全未隔离事务的情况下，两个事务更新同一条数据资源，某一事务完成，另一事务异常终止，回滚造成第一个完成的更新也同时丢失 。这个问题现代关系型数据库已经不会发生，就不在这里占用篇幅，有兴趣的可以自行百度。
脏读（Dirty Read）
A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读（Dirty Read）。脏读产生的流程如下：
不可重复读（Nonrepeatable Read）
B事务读取了两次数据，在这两次的读取过程中A事务修改了数据，B事务的这两次读取出来的数据不一样。B事务这种读取的结果，即为不可重复读（Nonrepeatable Read）。不可重复读的产生的流程如下：
不可重复读有一种特殊情况，两个事务更新同一条数据资源，后完成的事务会造成先完成的事务更新丢失。这种情况就是大名鼎鼎的第二类丢失更新。主流的数据库已经默认屏蔽了第一类丢失更新问题（即：后做的事务撤销，发生回滚造成已完成事务的更新丢失），但我们编程的时候仍需要特别注意第二类丢失更新。它产生的流程如下：
幻读（Phantom Read）
B事务读取了两次数据，在这两次的读取过程中A事务添加了数据，B事务的这两次读取出来的集合不一样。幻读产生的流程如下：
这个流程看起来和不可重复读差不多，但幻读强调的集合的增减，而不是单独一条数据的修改。
数据库隔离级别
为了解决上面提及的并发问题，主流关系型数据库都会提供四种事务隔离级别。
读未提交（Read Uncommitted）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别是最低的隔离级别，虽然拥有超高的并发处理能力及很低的系统开销，但很少用于实际应用。因为采用这种隔离级别只能防止第一类更新丢失问题，不能解决脏读，不可重复读及幻读问题。
读已提交（Read Committed）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别可以防止脏读问题，但会出现不可重复读及幻读问题。
可重复读（Repeatable Read）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。这种隔离级别可以防止除幻读外的其他问题。
可串行化（Serializable）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读、第二类更新丢失问题。在这个级别，可以解决上面提到的所有并发问题，但可能导致大量的超时现象和锁竞争，通常数据库不会用这个隔离级别，我们需要其他的机制来解决这些问题:乐观锁和悲观锁。
这四种隔离级别会产生的问题如下（网上到处都有，懒得画了）：
如何使用数据库的隔离级别
很多文章博客在介绍完这些隔离级别以后，就没有以后了。读的人一般会觉得，嗯，是这么回事，我知道了！
学习一个知识点，是需要实践的。比如下面这个常见而又异常严重的情况：
图中是典型的第二类丢失更新问题，后果异常严重。我们这里就以读已提交（Read Committed）及以下隔离级别中会出现不可重复读现象为例。从上面的表格可以看出，当事务隔离级别为可重复读（Repeatable Read）时可以避免。（事务隔离级别）
转自：https://www.cnblogs.com/yubaolee/p/10398633.html
悲观锁：
顾名思义，很悲观，就是每次拿数据的时候都认为别的线程会修改数据，所以在每次拿的时候都会给数据上锁。上锁之后，当别的线程想要拿数据时，就会阻塞，直到给数据上锁的线程将事务提交或者回滚。传统的关系型数据库里就用到了很多这种锁机制，比如行锁，表锁，共享锁，排他锁等，都是在做操作之前先上锁。
行锁：
下面演示行锁，打开两个mysql命令行界面，两个线程分别执行如下操作：（左边先执行）
左边的线程，在事务中通过select for update语句给sid = 1的数据行上了锁。右边的线程此时可以使用select语句读取数据，但是如果也使用select for update语句，就会阻塞，使用update，add，delete也会阻塞。
当左边的线程将事务提交（或者回滚），右边的线程就会获取锁，线程不再阻塞：
此时，右边的线程获取锁，左边的线程如果执行类似操作，也会被阻塞：
表锁：
上述例子中，如果使用如下语句就是使用的表锁：
select * from student for update;页锁：
行锁锁指定行，表锁锁整张表，页锁是折中实现，即一次锁定相邻的一组记录。
共享锁：
共享锁又称为读锁，一个线程给数据加上共享锁后，其他线程只能读数据，不能修改。
排他锁：
排他锁又称为写锁，和共享锁的区别在于，其他线程既不能读也不能修改。
乐观锁：
乐观锁其实不会上锁。顾名思义，很乐观，它默认别的线程不会修改数据，所以不会上锁。只是在更新前去判断别的线程在此期间有没有修改数据，如果修改了，会交给业务层去处理。
常用的实现方式是使用版本戳，例如在一张表中添加一个整型字段version，每更新version++，比如某个时刻version=1，线程A读取了此version=1，线程B也读取了此version=1，当线程A更新数据之前，判断version仍然为1，更新成功，version++变为2，但是当线程B再提交更新时，发现version变为2了，与之前读的version=1不一致，就知道有别的线程更新了数据，这个时候就会进行业务逻辑的处理。
通常情况下，写操作较少时，使用乐观锁，写操作较多时，使用悲观锁。
转载自：https://blog.csdn.net/xiangwanpeng/article/details/55106732
丢失更新： 当两个事物或多个事务都更新了同一条数据，但是这些事务彼此之间都不知道其他事务进行的修改，因此第二个更改覆盖了第一次的更改，说白了，就是事务A还没有提交之后，但是这个时候事务B更新了数据，那么事务A就丢失更新了。
解决方案： 乐观锁+悲观锁
悲观锁: 数据库的一种锁机制，悲观锁分成两种，分别是共享锁和排它锁
添加共享锁方式：select * from account lock in share mode ;
添加排它锁方式：select * from account for update;
下面说一下共享锁： 共享锁就是，例如 我在客户端A 给数据C 添加了共享锁，此时我在客户端B只能添加共享锁进行查看，没有修改的权利，如果我想要在客户端B进行修改，我只能在A处commit才能进行修改。
下面说一下排它锁：排它锁就是我在客户端A 给数据C添加了排它锁，那么我在客户端B只能在客户端 A commit之后，才能select数据，换句话说，只要我在客户端B用锁进行了查询，那我我都需要等待Acommit之后，如果此时我客户端B不加锁，我是可以查询到的。这个排它锁很像数据库隔离级别中的最高的隔离级别。但是排它锁是锁住了一条数据，而排它锁是锁上了这条数据。
说完了悲观锁，那么我们在说说乐观锁。
乐观锁：就是假设丢失更新不存在，它使用的是数据库的字段进行加测。 例如我在我的字段中添加一个字段，字段的类型是 timestamp 在插入和修改时 都会自动更新为当前时间 ，我根据我的sql条件进行判断，如果我的时间不符合，那么我的更新失败。
