本篇文章建议读者结合：
一同进行深入研究。
在进行MySQL事务讲解之前，我们先来一个银行转账的案列，将会通过这个案列带领大家深入了解事务的概念，特性等知识~~
经典的场景：银行转账~
用户1给用户2进行转账500money~
用户1给用户2进行转账500money~ account(id, balance) 1 1000 2 0 操作1： update account set balance = balance-500 where id=1; 操作2： update account set balance = balance+500 where id=2;
假设哈，假设~，在执行转账的过程中，执行完操作1以后，数据库崩溃/主机宕机，此时转账就僵硬了（操作1的钱扣了，操作2的钱没有正常到账）~~
那么事务，就是为了解决上述的问题~，事务的本质是把多个sql语句打包成一个整体（事务的原子性），要么全部都执行，要么就一个都不执行，而不会出现“执行一半的中间状态。
其实不是真的没执行，而是看起来好像跟没执行一样； 执行一半出错了，出错之后选择了恢复现场，把数据还原成未执行之前的状态了！ ————》类似于CTRL+Z(撤销） 这个恢复数据的操作叫做”回滚“
上面的这个银行转账案列跟淘宝买东西一个道理：如：淘宝买东西，下单的同时需要支付，若账户已扣钱，但是没有生成相对的订单表~~尴尬了这就！！
那么，我们回过来接着看一下刚刚的银行转账问题（操作1的钱扣了，操作2的钱未正常到账）
操作1： update account set balance = balance-500 where id=1; 操作2： update account set balance = balance+500 where id=2;
如果把这两个操作作为一个事务，当第一个sql执行完以后，数据库崩溃，当下次数据库重新启动完之后，就会自动的把上次修改一半的数据给进行还原（把操作1过程的-500元，再给+回来）。
进行回滚的时候，咋知道回滚是恢复到啥样的状态呢？？
此时是需要额外的部分来记录事务中的操作步骤（数据库里专门有个用来记录事务的日志）正因为如此，使用事务的时候，执行sql的开销是更大的，效率是更低的~~
开启事务/提交事务：
开启事务： start transaction; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~中间部分就是要执行的每一步操作 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 提交事务（到这一步，相当于事务就执行完了 commit;
如下述代码操作：
start transaction; 阿里巴巴账户减少2000 update account set money = money-2000 where name="阿里巴巴”; 四十大盗账户增加2000 update account set money = money+2000 where name="四十大盗”; commit;
大家看着上述的银行转账案列很容易，但是理解起来却是很困难~
那么接下来我们来看一下数据库的事务，四大特性（八股文，经典面试题）
- 原子性，（最核心的特性）初心
- 一致性，事务执行前后，数据得是靠谱的（转账金额）
- 持久性，事务修改的内容是写到硬盘上的，持久存在的，重启也不会丢失
- 隔离性，这个隔离性是为了解决“并发”执行事务，引起的问题
~~~~~~~~~~~~~最难搞的面试题~~~~~~~~~常考~~~~~~~~~~~~
我们先来了解一下并发：并发，在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行。——————内容来自百度百科~~
我们来举例说明一下并发：
在一个餐馆（服务器）同一时刻要给多个顾客（客户端）提供服务，这些顾客提出的请求是“一个接一个的？”，还是“一股脑来了一大批呢？”，此时服务器同时处理多个客户端的请求，称为“并发”（齐头并进）
引起的问题有哪些呢？？如果并发的这些事务是修改不同表/不同的数据，那么，没啥事，如果修改的是同一表/同一数据，可能会带来一定的问题，比如：多个客户端一起尝试对同一个账户进行转账操作，此时，就可以会把这个数据搞混了~
隔离性：事务的隔离性存在的意义是为了：在数据并发处理事务的时候，不会有问题（即使有问题，那么该问题也不大~）。
接下来说说：并发处理事务，可能会遇到哪些问题？？以及这些问题数据库的隔离性是怎样解决的？？（其实这个还是挺麻烦的，需要大家多理解理解）
并发执行事务可能产生的问题：
- 脏读问题
- 不可重复读
- 幻读
接下来，我们来看一下并发执行事务可能产生的三大问题吧~
1.脏读问题：
一个事务A正在对数据进行修改的过程中，还没提交之前，另一个事务B也对同一个数据进行了读取，此时B的读操作，就称为“脏读”，读到达数据也成为“脏数据”，此时所说的脏是指“无效的数据”，为啥说无效呢？？原因在于：A可能回头把数据给改了~~（事务B读到的数据不一定是最终结果，可能是无效的数据）
那么，我们又该如何取解决脏读问题呢？？
MySQL写了“写操作加锁”这样的机制~
当事务A修改数据到时候，事务B不能读数据，此时，事务A的“写操作”与事务B的“读操作”就不能并发了（不能同时执行了）
“写加锁操作”降低了并发程度（降低了效率）提高了隔离性（提高了事务的准确性）。
2.不可重复读
事务1已经提交了某数据，此时事务2开始去读数据，在读取的过程中，事务3对该数据进行了修改，并提交了新的数据，此时意味着：同一个事务2，多次读数据，读出来的结果是不相同的~（预期是一个事务中，多次读取结果得是一样的），此时，叫做“不可重复读”（第二次读取的结果，不能复现第一次的结果）
为了解决这个问题，MySQL引入“读加锁操作”
通过读加锁，又进一步降低了事务的并发处理能力（处理效率也降低了），提高事务的隔离性（数据的准确性又提高了~）
3.幻读
在读加锁和写加锁的前提下，一个事务两次读取同一个数据，发现读取的数据值是一样的，但是结果集不一样(student.java 代码内容不变，但是第一次看到的只有student.java文件，第二次看到的是student.java和teacher.java这两个文件），这种问题就是幻读
那么，又该如何解决幻读出现的问题呢？？
数据库使用“串行化”这样的方式来解决幻读，彻底放弃并发处理事务，一个接一个的串行的处理事务，这样做，并发程度是最低的（效率最慢的），隔离性是最高的（准确性是最高的）。
上述三个问题：脏读（给写加锁），不可重复读（给读加锁），幻读（彻底串行化）就是并发处理事务三个典型的问题~
对应上述问题MySQL提供四种隔离级别，对应上面的几个情况
- read uncommitted ： 没有进行任何锁限制，并发最高（效率最高），隔离性最低（准确性最低）~
- read committed ：给写加锁，并发程度降低，隔离性提高了~
- repeatable read ：给写和读加锁，并发程度又降低了，隔离性又提高了~
- serializable ：串行化，并发程度最低，隔离性最高~
上述的四个各类级别，都是MySQL内置的机制，可以通过修改MySQL的配置文件，来设置当前MySQL工作在哪种状态下~
对于上述的三个问题（脏读，不可重复读，幻读），没有办法通过代码来讲解
- 当前没有办法构造并发代码（涉及到多线程，笔者暂时不会嗨~~）
- 读加锁与写加锁啥的，都是MySQL内部的机制，不是代码~~
那么，对于上述的四个级别，该如何选择？？
其实这几个级别之间没有好坏之分，这就需要开发者在准确性和效率之间进行权衡，看实际需求，看业务场景~~
- 场景1：转账的时候，一分钱都不能差，哪怕慢点，也得转对，准确性要拉满，效率不关键
- 场景2：抖音点赞，一个视频有多少赞？要求快，赞的数量差十个八个的，都没啥事，追求的是效率，准确性就不怎么关键~
