1. 前言
后台开发过程中, 与数据库打交道是日常操作, 为了提高代码质量和程序性能, 数据库事务是必须理解深刻的, 这篇文章主要是记录数据库事务相关的概念和知识.
2. 事务
2.1 什么是事务
事务就是DBMS当中用户程序的任何一次执行, 事务是DBMS能看到的基本修改单元.
事务是指对系统进行的一组操作, 为了保证系统的完整性, 事务需要具有ACID特性.
2.2 为什么要有事务
事务的产生,其实是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题.可以想一下当我们使用事务时,要么提交,要么回滚,我们不会去考虑网络异常了,服务器宕机了,同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的.而不是伴随着数据库系统天生就有的.
2.3 ACID特性
2.3.1 原子性(Atomic)
事务是一个完整的操作. 事务的各步操作是不可分的(原子的); 要么都执行,要么都不执行.
2.3.2 一致性(Consistency)
当事务完成时, 数据必须处于一致状态. 即应用系统从一个正确的状态到另一个正确的状态.
2.3.3 隔离性(Isolation)
对数据进行修改的所有并发事务是彼此隔离的, 这表明事务必须是独立的, 它不应以任何方式依赖于或影响其他事务.
2.3.4 持久性(Durability)
事务完成后, 它对数据库的修改被永久保持, 事务日志能够保持事务的永久性.
2.4 隔离性详解
2.4.1 隔离级别
事务的隔离级别从低到高有:
Read Uncommitted: 最低的隔离级别, 什么都不需要做, 一个事务可以读到另一个事务未提交的结果. 所有的并发事务问题都会发生.
Read Committed: 只有在事务提交后, 其更新结果才会被其他事务看见. 可以解决脏读问题.
Repeated Read: 在一个事务中, 对于同一份数据的读取结果总是相同的, 无论是否有其他事务对这份数据进行操作, 以及这个事务是否提交. 可以解决脏读, 不可重复读.
Serialization: 事务串行化执行, 隔离级别最高, 牺牲了系统的并发性. 可以解决并发事务的所有问题.
通常, 在工程实践中, 为了性能的考虑会对隔离性进行折中.
其中只有serialization实现隔离性所有要求, 真正实现事务的隔离性.
但考虑到实践, 为了性能, 数据库厂商做出了这方面的妥协, 让使用者可以选择隔离的级别.
不同的隔离级别可以解决不同阶段的问题, 是层层递进, 逐渐增强的关系.
2.4.2 隔离性要解决的问题
隔离性为了解决的问题主要有三个(将事务的隔离级别和问题联系在一起理解):
1. 脏读(Drity Read): 事务A修改了一个数据, 但未提交, 事务B读到了事务A未提交的更新结果, 如果事务A提交失败, 事务B读到的就是脏数据. Read Committed可以解决脏读问题, 但仍存在以下两种问题.
2. 不可重复读(Non-repeatable read): 在同一个事务中, 对于同一份数据读取到的结果不一致. 比如, 事务B在事务A提交前读到的结果, 和提交后读到的结果可能不同. 不可重复读出现的原因就是事务并发修改记录, 要避免这种情况, 最简单的方法就是对要修改的记录加锁, 这导致锁竞争加剧, 影响性能.(另一种方法是通过MVCC可以在无锁的情况下, 避免不可重复读.) Repeated Read可以解决不可重复读问题和脏读问题, 但仍无法解决下面的问题.
3. 幻读(Phantom Read): 在同一个事务中, 同一个查询多次返回的结果不一致. 事务A新增了一条记录, 事务B在事务A提交前后各执行了一次查询操作, 发现后一次比前一次多了一条记录. 幻读仅指由于并发事务增加记录导致的问题, 这个不能像不可重复读通过记录加锁解决, 因为对于新增的记录根本无法加锁. 需要将事务串行化, 才能避免幻读. Serialization解决了以上所有问题, 但是性能效率较低.
通常来说, 事务隔离级别越低, 所需持有锁的时间也就越短, 并发性能也就越好.
3.参考链接
https://www.zhihu.com/question/31346392?sort=created
https://blog.csdn.net/zxl315/article/details/5388389
https://www.cnblogs.com/ws-astrologer/p/6681089.html