各位小伙伴有没遇到这个奇葩情况：业务逻辑对两个表加了事务操作，A表的存储引擎是InnoDB，B表的存储引擎却是MyISAM。事务要回滚时，麻烦就来了hhh，B表它回滚不了，那小伙伴打算要怎么处理~
🌱以【面试官面试】形式覆盖Java程序员所需掌握的Java核心知识、面试重点，本博客收录在我开源的《Java学习指南》中，会一直完善下去，希望收到大家的 ⭐ Star ⭐支持，这是我创作的最大动力： https://github.com/hdgaadd/JavaGetOffer
1. 事务的特性
面试官：事务的特性你说一说？
好的面试官。事务有四大特性。
- 原子性(atomicity)：一个事务必须是一个不可分割的最小工作单元，整个事务所有的操作，要么成功提交，要么都失败回滚。
- 一致性(consistency)：事务总是从一个一致性状态转换为另一个一致性状态。
- 隔离性(isolation)：一个事务所作出的修改在还没有提交之前，对其他事务来说是不可见的。
- 持久性(durability)：如果事务进行提交后，其所做的修改必须是永久性的，不会因为系统崩溃而丢失修改。
2. 事务隔离级别
面试官：隔离性有多种隔离级别，这个知道吧？
知道的，SQL标准定义了四种隔离级别，较低级别的隔离通常来说系统开销更低些。
- READ UNCOMMITTED（未提交读）：事务的修改，即使没有提交，对其他事务来说也是可见的。这是最低级别的事务隔离，企业生产中很少使用到。
- READ COMMITTED（提交读）：事务在未提交前，所做的修改对其他事务是不可见的。这个隔离级别也称为不可重复读，主要是因为两次重复的数据读取，可能会产生两种完全不同的结果。
- REPEATABLE READ（可重复读）：这个事务隔离级别保证了一个事务多次读取都是同样的结果，能够解决前面两个隔离级别可能产生的不可重复读问题。另外可重复读是
MySQL默认的事务隔离级别。 - SERIALIZABLE（可串行化）：该隔离级别会强制事务串行执行，同时对读取的每一行数据都加上锁，来。通过这种方式可以解决幻读的事务问题，不过可能导致锁竞争问题和大量的
SQL超时。
2.1 幻读
面试官：幻读是什么问题？还有其他事务问题吗？
并发事务带来的问题主要有四种，可以用上面我们谈到的事务隔离级别来处理，我都说下吧。
脏读：一个事务读取到另一个事务未提交的数据。
不可重复读：一个事务多次读取同一数据，另一个事务修改了该数据，导致第一个事务第二次读取数据发现和第一次读取的数据不一致。
幻读：一个事务多次读取同一数据，另一个事务给这些数据插入删除了某些内容，导致第一个事务数据的数量发生改变。
丢失修改：一个事务修改了某个数据，另一个事务与其读取同一数据且原始值都相同，另一个事务修改数据后提交，导致第一个事务的修改操作丢失。
2.1 处理幻读问题
面试官：那幻读要怎么解决？
可以采用我提到的SERIALIZABLE（可串行化）隔离级别来解决幻读，事务按顺序执行，也就不会有幻读问题。
MySQL也提供了其他方法来处理幻读问题。
设置间隙锁，在两个索引值之间的数据进行加锁，可以杜绝其他事务在这个范围内对数据数量的影响。
next-key锁就是间隙锁和行锁的组合，通过间隙锁锁住区间值、行锁锁住行本身。
2.3 死锁问题
面试官：事务加锁会导致死锁，要怎么处理？
是这样的，死锁是因为多个事务互相占用对方请求的资源导致的现象，要打破这个问题需要回滚其中一个事务，这样另一个事务就能获得请求资源了，而回滚的事务只需要重新执行即可。
InnoDB引擎目前处理死锁的方法是通过持有行级排他锁的数量来判断，持有最少行级排他锁的事务会进行回滚。
2.4 隔离级别相关命令
面试官：有去看看你们数据库用的什么隔离级别吗？
有的，MySQL默认隔离级别是可重复读，企业生产一般也是用的这个隔离级别。
查看隔离级别的指令：
select @@tx_isolation
设置隔离级别为可重复读的指令：
set session transaction isolation level repeatable read
未完待续。。。
创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️
