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