MySQL事务的性情很“原子“,要么执行要么不执行

2024-05-10 21:27:49 浏览数 (1)

各位小伙伴有没遇到这个奇葩情况:业务逻辑对两个表加了事务操作,A表的存储引擎是InnoDB,B表的存储引擎却是MyISAM。事务要回滚时,麻烦就来了hhh,B表它回滚不了,那小伙伴打算要怎么处理~

在这里插入图片描述在这里插入图片描述

1. 事务的特性

面试官:事务的特性你说一说?

好的面试官。事务有四大特性。

  1. 原子性(atomicity):一个事务必须是一个不可分割的最小工作单元,整个事务所有的操作,要么成功提交,要么都失败回滚。
  2. 一致性(consistency):事务总是从一个一致性状态转换为另一个一致性状态。
  3. 隔离性(isolation):一个事务所作出的修改在还没有提交之前,对其他事务来说是不可见的。
  4. 持久性(durability):如果事务进行提交后,其所做的修改必须是永久性的,不会因为系统崩溃而丢失修改。

2. 事务隔离级别

面试官:隔离性有多种隔离级别,这个知道吧?

知道的,SQL标准定义了四种隔离级别,较低级别的隔离通常来说系统开销更低些。

  1. READ UNCOMMITTED(未提交读):事务的修改,即使没有提交,对其他事务来说也是可见的。这是最低级别的事务隔离,企业生产中很少使用到。
  2. READ COMMITTED(提交读):事务在未提交前,所做的修改对其他事务是不可见的。这个隔离级别也称为不可重复读,主要是因为两次重复的数据读取,可能会产生两种完全不同的结果。
  3. REPEATABLE READ(可重复读):这个事务隔离级别保证了一个事务多次读取都是同样的结果,能够解决前面两个隔离级别可能产生的不可重复读问题。另外可重复读是MySQL默认的事务隔离级别。
  4. SERIALIZABLE(可串行化):该隔离级别会强制事务串行执行,同时对读取的每一行数据都加上锁,来。通过这种方式可以解决幻读的事务问题,不过可能导致锁竞争问题和大量的SQL超时。

2.1 幻读

面试官:幻读是什么问题?还有其他事务问题吗?

并发事务带来的问题主要有四种,可以用上面我们谈到的事务隔离级别来处理,我都说下吧。

  1. 脏读:一个事务读取到另一个事务未提交的数据。
  2. 不可重复读:一个事务多次读取同一数据,另一个事务修改了该数据,导致第一个事务第二次读取数据发现和第一次读取的数据不一致
  3. 幻读:一个事务多次读取同一数据,另一个事务给这些数据插入删除了某些内容,导致第一个事务数据的数量发生改变。
  4. 丢失修改:一个事务修改了某个数据,另一个事务与其读取同一数据且原始值都相同,另一个事务修改数据后提交,导致第一个事务的修改操作丢失。

2.1 处理幻读问题

面试官:那幻读要怎么解决?

可以采用我提到的SERIALIZABLE(可串行化)隔离级别来解决幻读,事务按顺序执行,也就不会有幻读问题。

MySQL也提供了其他方法来处理幻读问题。

  1. 设置间隙锁,在两个索引值之间的数据进行加锁,可以杜绝其他事务在这个范围内对数据数量的影响。
  2. next-key锁就是间隙锁和行锁的组合,通过间隙锁锁住区间值、行锁锁住行本身

2.3 死锁问题

面试官:事务加锁会导致死锁,要怎么处理?

是这样的,死锁是因为多个事务互相占用对方请求的资源导致的现象,要打破这个问题需要回滚其中一个事务,这样另一个事务就能获得请求资源了,而回滚的事务只需要重新执行即可。

InnoDB引擎目前处理死锁的方法是通过持有行级排他锁的数量来判断,持有最少行级排他锁的事务会进行回滚。

2.4 隔离级别相关命令

面试官:有去看看你们数据库用的什么隔离级别吗?

有的,MySQL默认隔离级别是可重复读,企业生产一般也是用的这个隔离级别。

查看隔离级别的指令:

代码语言:sql复制
select @@tx_isolation

设置隔离级别为可重复读的指令:

代码语言:sql复制
set session transaction isolation level repeatable read

我正在参与2024腾讯技术创作特训营最新征文,快来和我瓜分大奖!

未完待续。。。

0 人点赞