数据库———事务及bug的解决
阿华代码，不是逆风，就是我疯，你们的点赞收藏是我前进最大的动力！！希望本文内容能帮到你！
目录
一：事务
1：场景引入
2：“回滚”
3：恢复机制（undo log，redo log）
4：事务的特点
二：并发执行事务及Bug详解
1：场景引入
Bug（1）：“脏读”问题
①场景引入
②解决思路（给“写”上锁）
Bug（2）：不可重复读
①场景引入（沿用Bug1的场景）
②解决思路（给“读”上锁）
Bug（3）：幻读
①场景引入（沿用Bug2的场景）
②解决思路（）
三：隔离级别
1：read uncommitted（读未提交）
2：read committed（读已提交）
3：repeatable read （可重复读）
4：serializable（串行化）
四：实际运用（简述）
一：事务
1：场景引入
张三在银行账户中存有1000元，李四存有500元，这时张三要给李四支付500元，执行sql语句
①：update account set balance = balance -500 where name = '张三';
②：update account set balance = balance + 500 where name = '李四';
想象一下，如果在sql语句①执行完之后，数据库挂了，那不仅张三被扣了钱，李四还没有收到钱，问题就麻烦了
2：“回滚”
此时就引入了事务这一概念，“要么条sql语句都不执行，要么都执行”。
注：这里的不执行其实还是执行了的，“回滚”（rollback），恢复回去，这里涉及到数据库的一种恢复机制（undo log ， redo log）
3：恢复机制（undo log，redo log）
读法：（安度 老哥 ， 瑞都 老哥）哈哈
恢复机制会在数据库运行的时候，把你的操作写成日志的形式（println）保存到文件中，当数据库挂了之后，重启数据库，数据库会检查日志中是否有只执行了一半或者没有执行完的操作，如果有，就会把之前的操作进行回滚
优缺点：事务保证了数据的准确性，但是牺牲了执行效率
4：事务的特点
（1）原子性：事务的出现，本质就是将“操作”进行打包（这是事务的核心特性）
（2）一致性：是原子性的延伸，当数据库出现问题的时候，避免出现像上述钱不翼而飞的情况，即要么都执行，要么都不执行，另一方面我们也会添加一些约束条件，来避免数据出现一些非法的情况
（3）持久性：事务的操作是被写入硬盘的（持久保存的），电源关机，重启程序，这些修改的额操作都不会消失，（数据库本身就是为了持久化存储而生的）
（4）可隔离性：当多个事务并发操作时，可能会带来一些情况，我们可以通过隔离性来进行权衡，偏向数据的准确性多一点，或者偏向执行效率
二：并发执行事务及Bug详解
1：场景引入
数据库是cs结构的，一个数据库会面向多个服务器，当多个服务器同时向数据库发出事务请求，这就叫做并发执行事务。如果多个服务器请求的是修改不同的表那还好，如果是修改相同的表的话就会出现一些Bug
Bug（1）：“脏读”问题
①场景引入
服务器A：对数据库发出事务请求，修改了某个数据（写），但是还没有“提交”（提交的意思就是，告诉数据库，我的操作OK了，结束了）
服务器B：同时对数据库进行读取，读取了这个数据，但是这个数据并不一定是准确的，因为A后续还可能对数据进行修改，所以B的这一次读取操作就是“脏读”
通俗解释：考试中张三在写卷子，我过去瞄了一眼他写的答案，但是张三后面又修改成了正确答案，导致我抄的答案其实是错误的
②解决思路（给“写”上锁）
给操作“上锁”，在A对数据库操作的时候，（上锁），其它服务器不能访问，等到A的操作完成之后（解锁），后面的服务器才可以进行操作（看）
注意：这里的上锁是针对（写操作）服务器A
通俗解释：就是去上厕所，一个坑只能一个人上，坑里的人开门出来了，你才能进去
Bug（2）：不可重复读
①场景引入（沿用Bug1的场景）
服务器A在访问（写）数据库时候上锁了，服务器B在A结束操作之后开始第一次读取，此时进来一个服务器C（写）访问服务器，修改了数据，服务器B第二次读取数据发现：嘿怎么两次读取的数据不一致？？？
注：上锁是针对，服务器在数据库（写）修改数据的情况，没说你在读的时候，我不能修改呀！！
②解决思路（给“读”上锁）
在服务器“读”的时候也进行上锁。
不难发现Bug（2）和Bug（1）很像，就是（1）的一个延伸。
Bug（3）：幻读
①场景引入（沿用Bug2的场景）
服务器A上锁修改数据库数据，解锁后，服务器B开始第一次上锁读取，此时服务器C不修改数据了，C新增了一个数据，B第二次读取发现“结果集”发生了变化，王德发？？
解释“结果集”：就是类似表的行数
②解决思路（）
把并行事务串口化，不再进行任何并行开发，使用串口开发，一项事务执行完毕后，再继续下一项（实际开发中并行，串行视情况而定）
三：隔离级别
上述的的三种bug要根据实际开发情况来判定到底是否为bug，有的场景更注重与效率，有的场景更注重数据的准确性
1：read uncommitted（读未提交）
并行程度（高），隔离级别（低），效率（高），数据的准确性（低），可能会触发：“脏读”，“不可重复读”，“幻读”
2：read committed（读已提交）
并行程度（中），隔离级别（中），效率（中），数据的准确性（中），可能会触发：“不可重复读”，“幻读”
3：repeatable read （可重复读）
并行程度（低），隔离级别（高），效率（低），数据准确性（高），可能会触发：“幻读”
4：serializable（串行化）
并行程度（无了），隔离级别（最高），效率（最低），数据准确性（最准）
四：实际运用（简述）
1：start transaction（执行事务）
2：sql1，sql2，sql3语句进行打包
3：commit(告诉服务器，事务执行完毕)
4：roolback（告诉服务器，要进行回滚即开启事务后，执行的sql语句恢复回去）
roolback一般不会在控制台中执行，一般是在java代码中实现，先在代码中开启事务，控制执行sql语句（打包提交），结果某条sql语句报错，catch捕获异常，并且使用rollback（回滚）