为什么要使用事务
日常开发中，很多操作，不是通过一个SQL就能完成的，往往需要多个SQL配合完成
当执行多个SQL操作的时候，如果中间出现了特殊的情况（程序崩溃，系统奔溃，网络断开，主机掉电了……）可能就会出现前面的SQL执行成功，后面的SQL执行失败了
联系现实: 转账的时候，数据丢失
解决方案：使用事务来控制，保证以上两句SQL要么全部执行成功，要么全部执行失败
使用事务可以确保数据库中的一组操作要么全部成功，要么全部失败。这样可以保持数据库中的数据一致性。
事务的概念
事务指逻辑上的一组操作，组成这组操作的各个单元，要么全部成功，要么全部失败。
在不同的环境中，都可以有事务。对应在数据库中，就是数据库事务。
事务的四大特性
原子性❤️❤️
定义：把多个操作,打包成一个整体称为"原子性"
事务,把多个操作,打包成一个整体，能够保证，这个整体要么都执行成功，要么就一个都不执行。
从而有效避免，部分执行，部分未执行，产生的一些"中间状态引起的问题"
这里的都不执行不是真的不执行：
当事务中的若干个 sql 语句在一条一条的执行的，事务能够保证，当执行到某一条的时候如果出现问题了。
数据库就能够自动的把前面 sql 造成的影响，给恢复回去，恢复如初，看起来就好像一条SQL都没执行的样子。（把这里的“翻新"的操作，称为"回滚" (rollback)）
数据库事务的原子性,核心就是通过"回滚"机制来保证的
回滚实现的机制：
为了实现回滚机制，数据库会在执行事务的时候，记录日志.
当事务最终都执行完毕，中间没有差错，这些记录的内容就可以不要了，
但是如果执行事务的过程中，出现问题了, mysql就可以根据日志中记录的内容,来进行恢复操作.
- 之前进行了新增操作,就把数据删除掉.
- 之前进行了删除操作，就把数据新增上来
- 之前进行了修改操作,就把数据改回去
- 之前是查询操作,不影响,不需要任何恢复行为.
一致性❤️
定义：执行事务之前,和执行事务完毕之后，数据是一致的(不会出现这种"对不上"的情况)，是对数据正确的承诺
持久性也是和回滚有关的：
一旦触发回滚了，回滚回去的数据得是对的.
如果顺利执行没有触发回滚，数据也是要符合要求的.
联系现实体会数据一致性的重要性：
每个公司都有专门的会计岗位负责公司的账目，如果账目对不上，会计可能就会进去；
每个月的生活费，自认为没买什么东西，结果却是还没到月底，就没生活费了，剩余的时间就会很难熬，你心中关于生活费的记录和实际记录对不上，也就是数据的不一致
持久性❤️
定义：此处的持久指的是 程序重启/主机重启，数据仍然能存在
执行事务对数据库产生的修改，就会在硬盘上持久保存重启之后仍然存在；
如果存储在内存中,就不是持久的，内存中的数据会随着程序重启/主机重启而消失
至于 mysql 是如何提交后的事务一定会落到硬盘上的，这背后的原理是十分复杂的（(#’^.^# say: 你们的博主不会)）
隔离性 ❤️❤️❤️
定义：描述的是，数据库并发执行事务时，产生的情况
并发：多个客户端，同时给服务器，发起事务
每个客户端什么时候把事务提交过来?? 是不知道的，
很可能多个客户端正好就把事务赶到一块了，就需要数据库服务器都能给出处理，更糟糕的是,如果这多个事务都尝试操作同一个表，情况就会更复杂。
数据库服务器就需要把这多个事务都能处理好，就类似于一心多用
联系现实来理解：
就是一个餐馆，来了好几桌客人，每一桌客人都点了不同的菜，就需要确保每一桌都能够提供正确的服务，也要在正确的前提下，尽可能的提高效率
数据库一个一个处理事务，处理的速度会比较慢，如果要是一起同时处理，又会诞生出新的问题，
由此产生的三个典型问题：
- 脏读问题：事务B读到了事务A中未提交的临时数据(脏数据) => 解决：写加锁
- 不可重复读：事务B读的过程中，又有一个事务C对刚才事务A提交的数据进行了修改，使事务B内部不同的读操作读到的结果不同 => 解决：读加锁
- 幻读：和不可重复读类似，事务B读的过程中，事务C没有修改数据内容，而是修改了“结果集"，导致B内部不同的读操作读到的结果集合不同 => 解决：串行化
注：关于并发执行事务过程中产生的三个典型问题这部分内容，后面博主会再写一篇博客进行阐述，并把博客链接放在文章末尾。
博主(#^.^#)：创作不易，动动你们的小手 点赞，收藏 + 关注哟！😍😍😍
