前言

  • 事务就是对一系列的数据库操作(比如插入多条数据)进行统一的提交或回滚操作,如果插入成功,那么一起成功,如果中间有一条出现异常,那么回滚之前的所有操作。

  • 这样可以防止出现脏数据,防止数据库数据出现问题。

解析

事务的特性 ACID

  • 原子性 Atomicity :一个事务(transaction)中的所有操作,或者全部完成,或者全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被恢复(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。即,事务不可分割、不可约简。
  • 一致性 Consistency :在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
  • 隔离性 Isolation :数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括
    • 读未提交(Read uncommitted)
    • 读提交(read committed)
    • 可重复读(repeatable read)
    • 串行化(Serializable)。
  • 持久性 Durability :事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。

事务的并发问题

MySQL 事务隔离级别会产生的并发问题

  • 事务定义了四种事务隔离级别,不同数据库在实现时,产生的并发问题是不同的,不同的隔离级别有不同的现象,并有不同的锁定/并发机制,隔离级别越高,数据库的并发性就越差。
1、读未提交(Read uncommitted)
  • 读未提交,顾名思义,就是一个事务可以读取另一个未提交事务的数据,事务中的修改,即使没有提交,对其他事务也都是可见的。

  • 事例:老板要给程序员发工资,程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字,按成3.9万/月,该钱已经打到程序员的户口,但是事务还没有提交,就在这时,程序员去查看自己这个月的工资,发现比往常多了3千元,以为涨工资了非常高兴。但是老板及时发现了不对,马上回滚差点就提交了的事务,将数字改成3.6万再提交。

  • 分析:实际程序员这个月的工资还是3.6万,但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是脏读

  • 这样的话会导致脏读,那怎么解决脏读呢?Read committed!读提交,能解决脏读问题。

2、读提交(read committed)
  • 读提交,顾名思义,就是一个事务要等另一个事务提交后才能读取数据,事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。

  • 事例:程序员拿着信用卡去享受生活(卡里当然是只有3.6万),当他埋单时(程序员事务开启),收费系统事先检测到他的卡里有3.6万,就在这个时候!!程序员的妻子要把钱全部转出充当家用,并提交。当收费系统准备扣款时,再检测卡里的金额,发现已经没钱了(第二次检测金额当然要等待妻子转出金额事务提交完)。程序员就会很郁闷,明明卡里是有钱的…

  • 分析:这就是读提交,若有事务对数据进行更新(UPDATE)操作时,读操作事务要等待这个更新操作事务提交后才能读取数据,可以解决脏读问题。但在这个事例中,出现了一个事务范围内两个相同的查询却返回了不同数据,这就是不可重复读

  • 这个隔离级别会导致不可重复读,也可以叫做“不可重复读“,那怎么解决不可重复读问题?Repeatable read !可重复读能解决

3、可重复读(repeatable read)
  • 重复读就是在开始读取数据(事务开启)时,不再允许修改操作

  • 事例:程序员拿着信用卡去享受生活(卡里当然是只有3.6万),当他埋单时(事务开启,不允许其他事务的UPDATE修改操作),收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

  • 分析:重复读可以解决不可重复读问题。写到这里,应该明白的一点就是,不可重复读对应的是修改,即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作,而不是UPDATE操作

  • 什么时候会出现幻读?

    • 事例:程序员某一天去消费,花了2千元,然后他的妻子去查看他今天的消费记录(全表扫描FTS,妻子事务开启),看到确实是花了2千元,就在这个时候,程序员花了1万买了一部电脑,即新增INSERT了一条消费记录,并提交。当妻子打印程序员的消费记录清单时(妻子事务提交),发现花了1.2万元,似乎出现了幻觉,这就是幻读。
    • 那怎么解决幻读问题?Serializable!
4、串行化(Serializable)。
  • Serializable 是最高的事务隔离级别,在该级别下,事务串行化顺序执行,可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下,比较耗数据库性能,一般不使用。

MySQL 默认的事务隔离级别为可重复读(repeatable-read)

  • 实现结果如下表所示:
事务隔离级别脏读不可重复读幻读
读未提交(read-uncommitted)
读已提交(read-committed)
可重复读(repeatable-read)是(x)
串行化(serializable)
  • 这里需要注意的是:与 SQL 标准不同的地方在于 InnoDB 存储引擎在 REPEATABLE-READ(可重读) 事务隔离级别下使用的是Next-Key Lock 锁算法,因此可以避免幻读的产生,这与其他数据库系统(如 SQL Server) 是不同的。所以说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读) 已经可以完全保证事务的隔离性要求,即达到了 SQL标准的 SERIALIZABLE(可串行化) 隔离级别。因为隔离级别越低,事务请求的锁越少,所以大部分数据库系统的隔离级别都是 READ-COMMITTED(读取提交内容) ,但是你要知道的是InnoDB 存储引擎默认使用 REPEAaTABLE-READ(可重读) 并不会有任何性能损失。

  • InnoDB 存储引擎在 分布式事务 的情况下一般会用到 SERIALIZABLE(可串行化) 隔离级别。

  • MySQL InnoDB 采用 MVCC 来支持高并发

  • 值得一提的是:大多数数据库默认的事务隔离级别是Read committed,比如Sql Server , OracleMysql的默认隔离级别是Repeatable read

总结

  • 数据库事务的隔离级别有4种,由低到高分别为1、读未提交 2、读提交 3、可重复读 4、串行化,前三种级别因为事务并不是串行的,所以会带来如下三个问题:
    • 1、脏读:事务 A 读取了事务 B 提交前更新的数据,然后 B 回滚操作,那么 A 读取到的数据是脏数据。
    • 2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务 A 多次读取的过程中,对数据作了更新并提交,导致事务 A 多次读取同一数据时,结果不一致。
    • 3、幻读:系统管理员 A 将数据库中所有学生的成绩从具体分数改为 ABCDE 等级,但是系统管理员 B 就在这个时候插入了一条具体分数的记录,当系统管理员 A 改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这就叫幻读。
  • 小结:
    • 不可重复读的和幻读很容易混淆
    • 不可重复读侧重于修改,解决不可重复读的问题只需锁住满足条件的行
    • 幻读侧重于新增或删除,解决幻读需要锁表

参考