大家好，我是陈哈哈，北漂五年。认识我的朋友们知道，我是非科班出身，半路出家，大学也很差！这种背景来北漂，你都不知道你会经历什么。

不敢苟同，相信大家和我一样，，作为一名资深Java选手，深知面试重要性，接下来我准备用100天时间，基于Java岗面试中的高频面试题，以的形式，带你过一遍热门面试题及恰如其分的解答。当然，我不会太深入，因为我怕记不住！！

，希望这100天能够让我们有质的飞越，一起冲进大厂！！，让我们一起学（juan）起来！！！

深入追问：

追问1：说一下你对ACID四大特性的理解

该问题来自“MySQL江湖路”专栏中的博文：《数据库ACID四大特性到底为了啥，一文带你看通透》

ACID特性：原子性、一致性、隔离性、持久性

• 原子性(Atomicity)

，整个事务中的所有操作要么全部commit成功，要么全部失败rollback，对于一个事务来说，不可能只执行其中的一部分SQL操作，这就是事务的原子性。

• 一致性(Consistency)

数据库总是从一个一致性的状态转换到另外一个一致性的状态。在前面的例子中， 一致性确保了，即使在执行第三、四条语句之间时系统崩潰，信用卡账户也不会损 失100块，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中，保证数据一致性。

• 隔离性(Isolation)

通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。在前面 的例子中，当执行完第三条语句、第四条语句还未开始时，此时有另外一个账户查询余额SQL开始运行，则其看到的信用卡账户的余额并没有被减去100元。后面我们讨论隔离级别(Isolation level)的时候，会发现为什么我们要说。

• 持久性(Durability)

一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。

事务的ACID特性可以确保银行不会弄丢你的钱。而在应用逻辑中，要实现这一点非常难, 甚至可以说是不可能完成的任务。一个兼容ACID的数据库系统，需要做很多复杂但可能用户并没有觉察到的工作，才能确保ACID的实现。

追问2：可以从原理上聊一下ACID具体是怎么实现的么/h3>

对MySQL来说，。

• 原子性：通过undolog来实现。
• 持久性：通过binlog、redolog来实现。
• 隔离性：通过(读写锁+MVCC)来实现。
• 一致性：

1、原子性原理

事务通常是以BEGIN TRANSACTION 开始，以 COMMIT 或 ROLLBACK 结束。

• ，即提交事务的所有操作并持久化到数据库中。
• ，即在事务中运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库所有已完成的操作全部撤销，回滚到事务开始时的状态，这里的操作指对数据库的更新操作，已执行的查询操作不用管。这时候也就需要用到 undolog 来进行回滚。

undolog：

1. 每条数据变更（INSERT/UPDATE/DELETE/REPLACE）等操作都会生成一条undolog记录，在SQL执行前先于数据持久化到磁盘。
2. 当事务需要回滚时，MySQL会根据回滚日志对事务中已执行的SQL做逆向操作，比如 DELETE 掉一行数据的逆向操作就是再把这行数据 INSERT回去，其他操作同理。

2、持久性原理

先了解一下MySQL的数据存储机制，MySQL的表数据是存放在磁盘上的，因此想要存取的时候都要经历磁盘 IO,然而即使是使用 SSD 磁盘 IO 也是非常消耗性能的。为此，为了提升性能 InnoDB 提供了缓冲池(Buffer Pool)，Buffer Pool 中包含了磁盘数据页的映射，可以当做缓存来使用：

• 读数据：会首先从缓冲池中读取，如果缓冲池中没有，则从磁盘读取在放入缓冲池；
• 写数据：会首先写入缓冲池，缓冲池中的数据会定期同步到磁盘中；

我们知道，MySQL表数据是持久化到磁盘中的，但如果所有操作都去操作磁盘，等并发上来了，那处理速度谁都吃不消，因此引入了的概念，Buffer Pool 中包含了磁盘中部分数据页的映射，可以当做缓存来用；这样当修改表数据时，我们把操作记录先写到Buffer Pool中，并标记事务已完成，等MySQL空闲时，再把更新操作持久化到磁盘里（），从而大大缓解了MySQL并发压力。

但是它也带来了新的问题，当MySQL系统宕机，断电时Buffer Pool数据不就丢了/p>

因为我们的数据已经提交了，但此时是在缓冲池里头，还没来得及在磁盘持久化，所以我们急需一种机制需要存一下已提交事务的数据，为恢复数据使用。

于是 redo log + binlog的经典组合就登场了，这里不在扩展赘述。可参考《听我讲完redo log、binlog原理，面试官老脸一红》

3、隔离性原理

隔离性是事务ACID特性里最复杂的一个。在SQL标准里定义了四种隔离级别，每一种级别都规定一个事务中的修改，哪些是事务之间可见的，哪些是不可见的。

级别越低的隔离级别可以执行越高的并发，但同时实现复杂度以及开销也越大。

搞懂MySQL事务隔离级别请参考《上个厕所的功夫，搞懂MySQL事务隔离级别》

Mysql 隔离级别有以下四种（级别由低到高）：

隔离级别	效果
读未提交（RU）	一个事务还没提交时，它做的变更就能被别的事务看到。（别的事务指同一时间进行的增删改查操作）
读提交（RC）	一个事务提交（commit）之后，它做的变更才会被其他事务看到。
可重复读（RR）	一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。 当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
串行（xíng）化（S）	正如物理书上写的，串行是单线路，顾名思义在MySQL中同一时刻只允许单个事务执行，“写”会加“写锁”，“读”会加“读锁”。 当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

搞懂了隔离级别以及实现原理其实就可以理解ACID里的隔离性了。前面说过原子性，隔离性，持久性的目的都是为了要做到一致性，但隔离型跟其他两个有所区别，原子性和持久性是为了要实现数据的正确、可用，比如要做到宕机后的恢复、事务的回滚等，保证数据是正确可用的！

那么隔离性是要做到什么呢/p>

隔离性要管理的是：多个并发读写请求（事务）过来时的执行顺序。像交警在马路口儿指挥交通一样，

课间休息，欣赏一下来自咱们同学的搬砖工地，坐标：杭州。

---

面试题2：并发场景下事务会存在哪些数据问题/h1>

正经回答：

并发场景下MySQL事务可能会出现脏读、幻读、不可重复读问题；

• 脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。
• 不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新了原有的数据。
• 幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

深入追问：

追问1：那Innodb是如何解决幻读问题的呢/h3>

先说结论，MySQL 存储引擎 InnoDB 在可重复读（RR）隔离级别下是解决了幻读问题的。

方法是通过next-key lock在当前读事务开启时，1.给涉及到的行加写锁（行锁）防止写操作；2.给涉及到的行两端加间隙锁(Gap Lock)防止新增行写入；从而解决了幻读问题。

幻读出现的场景：

• 幻读出现在可重复读（RR）隔离级别下，普通的SELECT查询就是快照读，是不会看到别的事务插入的数据的。因此，幻读在“当前读”下才会出现。（当前读会生成行锁，但行锁只能锁定存在的行，针对新插入的操作没有限定）
• 上面 session B 的修改结果，被 session A 之后的 select 语句用“当前读”看到，不能称为幻读。幻读仅专指“新插入的行”。
• 因为这三个查询都是加了 for update，都是当前读。而当前读的规则，就是要能读到所有已经提交的记录的最新值。并且，session B 和 sessionC 的两条语句，执行后就会提交，所以 Q2 和 Q3 就是应该看到这两个事务的操作效果，而且也看到了，这跟事务的可见性规则并不矛盾。

幻读场景实例：

测试表数据如下：

下面是一个出现幻读情况的示例流程：

时刻T	Session A	Session B	Session C
T1	begin; – Query1 select * from LOL where price=450 for update; Result：(6,‘无极剑圣’,450)
T2		update LOL set price=450 where hero_title = ‘疾风剑豪’;
T3	– Query2 select * from LOL where price=450 for update; Result：(6,‘无极剑圣’,450),(7,‘疾风剑豪’,450)
T4			insert into LOL values(10,‘雪人骑士’,‘努努’,‘450’);
T5	– Query3 select * from LOL where price=450 for update; Result：(6,‘无极剑圣’,450),(7,‘疾风剑豪’,450),(10,‘雪人骑士’,450)
T6	commit;

可以看到，session A 里执行了三次查询，分别是 Q1、Q2 和 Q3。它们的 SQL 语句相同，都是 select * from LOL where price=450 for update。这个语句的意思你应该很清楚了，查所有 price=450 的行，而且使用的是当前读，并且加上写锁。现在，我们来看一下这三条 SQL 语句，分别会返回什么结果。

1. Q1 只返回 “无极剑圣” 这一行；
2. 在 T2 时刻，session B 把 “疾风剑豪” 这一行的 price 值改成了 450，因此 T3 时刻 Q2 查出来的是 “无极剑圣” 和 “疾风剑豪” 这两行；
3. 在 T4 时刻，session C 又插入一行 (10,‘雪人骑士’,‘努努’,‘450’)，因此 T5 时刻 Q3 查出来 price = 450 的是”无极剑圣” 、“疾风剑豪” 和 “雪人骑士” 这三行。

其中，Q3 读到 (10,‘雪人骑士’,450) 这一行的现象，被称为“幻读”。也就是说，幻读指的是一个事务在前后两次查询同一个范围的时候，

解决幻读原理分析

如果你看到了这里，那么我会默认你了解了脏读 、不可重复读与可重复读。如果还不清楚可以先参阅《上个厕所的功夫，搞懂MySQL事务隔离级别》

场景如上，场景隔离级别为RR，当前读。

一、原理解读

那么幻读能仅通过行锁解决么案是否定的，如上面示例，首先说明一下，是将所有条件涉及到的（符合where条件）行加上行锁。但是，就算我在select xx for update 事务开启时将所有的行都加上行锁。那么也锁不住Session C新增的行，因为在我给数据加锁的时刻，压根就还没有新增的那行，自然也不会给新增行加上锁。

所以要解决幻读，就必须得解决新增行的问题。

现在你应该明白了，产生幻读的原因是：行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB 只好引入新的锁，也就是间隙锁 (Gap Lock)。顾名思义，间隙锁，锁的就是两个值之间的空隙。比如文章开头的表 LOL，初始化插入了 7 个记录，这就产生了 8 个间隙。

1. 按锁粒度从大到小分类：，和；以及特殊场景下使用的

2. 如果按锁级别分类则有：、、、；

3. 以及Innodb引擎为解决幻读等并发场景下事务存在的数据问题，引入的、、等；

4. 还有就是我们面向编程的两种锁思想：悲观锁、乐观锁。

深入追问：

追问1：那你来谈一谈你对表锁、行锁的理解吧。

表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。

当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，大大降低并发度。

使用表级锁定的主要是MyISAM，MEMORY，CSV等一些非事务性存储引擎。

与表锁正相反，行锁最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力从而提高系统的整体性能。

虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，。

使用行级锁定的主要是InnoDB存储引擎。

• ：从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新数据的情况，同时又有并发查询的应用场景。

除了表锁、行锁外，MySQL还有一种相对偏中性的锁，页锁是MySQL中比较独特的一种锁定级别，在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。

使用页级锁定的主要是BerkeleyDB存储引擎。

追问2：那全局锁是什么时候用的呢/h3>

首先全局锁，是对整个数据库实例加锁。使用场景一般在时。

MySQL提供加全局读锁的命令： (FTWRL)

这个命令可以使整个库处于只读状态。使用该命令之后，数据更新语句、数据定义语句和更新类事务的提交语句等修改数据库的操作都会被阻塞。

风险：

1. 如果在主库备份，在备份期间不能更新，业务停摆
2. 如果在从库备份，备份期间不能执行主库同步的binlog，导致主从延迟同步

还有一种锁全局的方式： ，相当于将整个库设置成只读状态，但这种修改global配置量级较重，和全局锁不同的是：如果执行 命令后，如果客户端发生异常断开，那么MySQL会自动释放这个全局锁，整个库回到可以正常更新的状态。但将库设置为readonly后，客户端发生异常断开，数据库依旧会保持readonly状态，会导致整个库长时间处于不可写状态，试想一下微信只能看，不能打字~~

追问2：那你再说一下按锁级别划分的那几种锁的使用场景和理解吧/h3>

MySQL基于锁级别又分为：、、、

对于、，比如咱们住酒店，入住前顾客都是有权看房的，只看不住想白嫖都是可以的，前台小姐姐会把门给你打开。当然，也允许不同的顾客一起看（），比如和这位杀马特小伙子。

MySQL江湖路 微信公众号 专注高性能MySQL领域以及百日冲刺更新~

来源：_陈哈哈