标签：事务 快照 幻读 数据库 重复 详解 脏读 提交 mysql

        众所周知MySQL从5.5.8开始，Innodb就是默认的存储引擎，Innodb最大的特点是：支持事务、支持行级锁。 既然支持事务，那么就会有处理并发事务带来的问题：更新丢失、脏读、不可重复读、幻读；相应的为了解决这四个问题， 就产生了事务隔离级别：未提交读(Read uncommitted)，已提交读(Read committed)，可重复读(Repeatable read)，可序列化(Serializable)。下面通过事例一一阐述它们的概念与联系

1.事务的特性：

原子性：指处于同一个事务中的多条语句是不可分割的。即它对数据库的修改要么全部执行，要么全部不执行

一致性：事务必须使数据库从一个一致性状态变换到另外一个一致性状态。比如转账，转账前两个账户余额之和为2k，转账之后也应该是2K。

隔离性：指多线程环境下，一个线程中的事务不能被其他线程中的事务打扰

持久性：事务一旦提交，就应该被永久保存起来。

2.处理并发事务出现问题的概念说明：

更新丢失：最后的更新覆盖了其他事务之前的更新，而事务之间并不知道，发生更新丢失。更新丢失，可以完全避免，应用对访问的数据加锁即可。

脏读(针对未提交的数据)：指当一个事务正在访问数据，并且对数据进行了修改，而这种数据还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。

例子：
1.财务将董震的工资从1000修改成了8000（但未提交事务）
2.此时应董震读取自己的工资发现自己的工资变成了8000，高兴的上蹦下跳
3.接着财务发现操作有误，回滚了事务，此时董震的工资又变成了1000，此时董震记取的工资8000是一个 脏数据

不可重复读(读取数据本身的对比)：指在一个事务内，多次读同一数据。在这个事务还没有执行结束，另外一个事务也访问该同一数据，那么在第一个事务中的两次读取数据之间，由于第二个事务的修改第一个事务两次读到的数据可能是不一样的，这样就发生了在一个事物内两次连续读到的数据是不一样的，这种情况被称为是不可重复读。

幻读(读取结果集条数的对比)：幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到了表中的全部数据行。同时，第二个事务也修改了这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好像发生了幻觉一样

例子：
目前公司员工工资为1000的有10人
1.事务1读取所有的员工工资为1000的员工。
2.这时事务2向employee表插入了一条员工纪录，工资也为1000
3.事务1再次读取所有工资为1000的员工，共读取了11条记录。
这就是一个幻读

3.事务隔离级别

        并发处理带来的问题中，更新丢失可以完全避免，由应用对数据加锁即可。脏读、不可重读度、幻读，其实都是数据库的一致性问题，必须由一定的事务隔离机制来解决。 其中一种方法是：不用加锁，通过一定的机制生成一个数据请求时间点的一致性快照，并用这个快照来提供一个界别的一致性读取。从用户的角度看，好像是数据库提偶拱了 统一数据的多个版本。这种技术叫做：数据库多版本并发控制，MVCC 多版本数据库。

        事务隔离的本质是使事务在一定程度上串行化执行，显然和并发机制是矛盾的。数据库的事务隔离越严格，并发负作用越小，代价越高(影响并发访问)。

为了解决隔离和并大的矛盾，IOS SQL92规定了4个隔离级别。(隔离==串行)

 大多数数据库默认的事务隔离级别是 读未提交(Read Committed)，比如 SQL Server , Oracle。但 MySQL 的默认隔离级别是 可重复读(Repeatable Read)

未提交读 （Read uncommitted）

　　未提交读，顾名思义，就是一个事务可以读取另一个未提交事务的数据。

　　事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。

　　分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是脏读。因此，在这种隔离级别下，查询是不会加锁的，也由于查询的不加锁，所以这种隔离级别的一致性是最差的，可能会产生“脏读”、“不可重复读”、“幻读”。如无特殊情况，基本是不会使用这种隔离级别的。

　　那怎么解决脏读呢？Read committed(已提交读)，能解决脏读问题。

已提交读（Read Committed）

　　已提交读，顾名思义，就是只能读到已经提交了的内容

　　事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（程序员事务开启），收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了（第二次检测金额当然要等待妻子转出金额事务提交完）。程序员就会很郁闷，明明卡里是有钱的…

　　分析：这就是已提交读，若有事务对数据进行更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。

 　　这是各种系统中最常用的一种隔离级别，也是SQL Server和Oracle的默认隔离级别。这种隔离级别能够有效的避免脏读，但除非在查询中显示的加锁，如：

select * from T where id=1lock in share mode;
select * from T where id=1 for update;

　　不然，普通的查询是不会加锁的。

　　那为什么“已提交读”同“未提交读”一样，都没有查询加锁，但是却能够避免脏读呢？

　　这就要说道另一个机制“快照（snapshot）”，而这种既能保证一致性又不加锁的读也被称为“快照读（Snapshot Read）”

　　假设没有“快照读”，那么当一个更新的事务没有提交时，另一个对更新数据进行查询的事务会因为无法查询而被阻塞（因为上了X锁，即写锁，所以不能得到S锁，即读锁），这种情况下，并发能力就相当的差。而“快照读”就可以完成高并发的查询，不过，“读提交”只能避免“脏读”，并不能避免“不可重复读”和“幻读”。

　　那怎么解决可能的不可重复读问题？Repeatable read(可重复读)

可重复读(Repeated Read)

　　可重复读，顾名思义，就是专门针对“不可重复读”这种情况而制定的隔离级别，自然，它就可以有效的避免“不可重复读”。而它也是MySql的默认隔离级别。

　　事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（事务开启，不允许其他事务的UPDATE修改操作），收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

　　分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。

什么时候会出现幻读？

　　事例：程序员某一天去消费，花了2千元，然后他的妻子去查看他今天的消费记录（全表扫描FTS，妻子事务开启），看到确实是花了2千元，就在这个时候，程序员花了1万买了一部电脑，即新增INSERT了一条消费记录，并提交。当妻子打印程序员的消费记录清单时（妻子事务提交），发现花了1.2万元，似乎出现了幻觉，这就是幻读。

　　在这个级别下，普通的查询同样是使用的“快照读”，但是，和“已提交读”不同的是，当事务启动时，就不允许进行“修改操作（Update）”了，而“不可重复读”恰恰是因为两次读取之间进行了数据的修改，因此，“可重复读”能够有效的避免“不可重复读”，但却避免不了“幻读”，因为幻读是由于“插入或者删除操作（Insert or Delete）”而产生的。

　　那怎么解决幻读问题？Serializable(可序列化)

可序列化 (Serializable)

　　这是数据库最高的隔离级别，这种级别下，事务“串行化顺序执行”，也就是一个一个排队执行。这种级别下，“脏读”、“不可重复读”、“幻读”都可以被避免，但是执行效率奇差，性能开销也最大，所以基本没人会用。

MySql如何解决幻读问题？

（1）什么是幻读

• 前提条件：InnoDB引擎，可重复读隔离级别，使用当前读时。

　   在一次事务里面，多次查询之后，结果集的个数不一致的情况叫做幻读。而多出来或者少的哪一行被叫做 幻行

• 表现：一个事务(同一个read view)在前后两次查询同一范围的时候，后一次查询看到了前一次查询没有看到的行。两点需要说明：
  　　1、在可重复读隔离级别下，普通查询是快照读，是不会看到别的事务插入的数据的，幻读只在当前读下才会出现。
  　　2、幻读专指新插入的行，读到原本存在行的更新结果不算。因为当前读的作用就是能读到所有已经提交记录的最新值。

（2）幻读产生的原因

　　行锁只能锁住行，即使把所有的行记录都上锁，也阻止不了新插入的记录。 

（3）如何解决幻读？

• 在快照读读情况下，mysql通过mvcc来避免幻读
• 在当前读读情况下，mysql通过next-key来避免幻读

什么是快照读、当前读

快照读:读取专门的快照 (对于RC，快照（ReadView）会在每个语句中创建。对于RR，快照是在事务启动时创建的)
```
简单的select操作即可(不需要加锁,如: select ... lock in share mode, select ... for update)
```
针对的也是select操作

当前读: 读取最新版本的记录, 没有快照。 在InnoDB中，当前读取根本不会创建任何快照。
```
select ... lock in share mode

select ... for update

insert

update

delete

针对如下操作, 会让如下操作阻塞:    
```
insert
update
delete
```
在RR(可重复读)级别下, 快照读是通过MVVC(多版本控制)和undo log来实现的,

当前读是通过手动加record lock(记录锁)和gap lock(间隙锁)来实现的。所以从上面的显示来看，如果需要实时显示数据，还是需要通过加锁来实现。这个时候会使用next-key技术来实现

总结：

• 为什么会出现“脏读”？因为没有“select”操作没有规矩。
• 为什么会出现“不可重复读”？因为“update”操作没有规矩。
• 为什么会出现“幻读”？因为“insert”和“delete”操作没有规矩。
• “读未提（Read Uncommitted）”能预防啥？啥都预防不了。
• “读提交（Read Committed）”能预防啥？使用“快照读（Snapshot Read）”，避免“脏读”，但是可能出现“不可重复读”和“幻读”。
• “可重复读（Repeated Red）”能预防啥？使用“快照读（Snapshot Read）”，锁住被读取记录，避免出现“脏读”、“不可重复读”，但是可能出现“幻读”。
• “串行化（Serializable）”能预防啥？有效避免“脏读”、“不可重复读”、“幻读”，不过执行效率奇差，性能开销也最大，所以基本没人会用

标签：事务,快照,幻读,数据库,重复,详解,脏读,提交,mysql
来源： https://blog.csdn.net/zhoupenghui168/article/details/122515748

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。