互联网公司数据库面试题整理：事务特性、并发控制与存储引擎详解

当我加入互联网公司时，我整天只是搬砖。到了面试的时候，我发现自己已经忘记了关于数据库的一切，于是我就花时间整理了一些数据库问题。欢迎大家向我推荐你在面试中遇到的问题。我会将您推荐的问题添加到下面的常用面试问题列表中，供您参考。

事务（ACID）的四个特性是什么：原子性、一致性、隔离性和持久性？交易的并发性？事务隔离级别，每个级别会导致什么问题，MySQL默认是哪个级别？ MySQL中常见的三种存储引擎（InnoDB、MyISAM、MEMORY）有什么区别？ MySQL的MyISAM和InnoDB存储引擎的事务和锁级别适用于哪些场景？查询语句的不同元素（where、jion、limit、group by、having 等）的执行顺序是怎样的？什么是临时表？临时表什么时候删除？ MySQL B+Tree索引和Hash索引有什么区别？ SQL查询语句决定创建什么类型的索引？如何优化查询？聚集索引和非聚集索引有什么区别？锁有哪些类型（乐观锁和悲观锁），选择时如何添加排它锁？非关系型数据库和关系型数据库有哪些区别以及各自的优势？数据库三种范式，根据某种场景设计数据表？数据库读写分离，主从复制，7个问题主从复制分析？使用explain来优化sql和索引？如何解决MySQL查询慢的问题？什么是内连接、外连接、交叉连接、笛卡尔积等？ MySQL有哪些类型的锁？死锁判定原则和具体场景是什么？如何解决僵局？ varchar和char的使用场景有哪些？ Mysql高并发环境解决方案？数据库崩溃时事务恢复机制（REDO日志和UNDO日志）是怎样的？ 1、事务（ACID）四大特性是什么：原子性、一致性、隔离性、持久性？

原子性

一致性

隔离

同时，只允许一个事务请求相同的数据，不同事务之间互不干扰。例如，A正在从银行卡取款。在 A 的提款流程完成之前，B 无法向该卡转账。

关于事务隔离，数据库提供了多种隔离级别，后面会介绍。耐用性

2. 交易的并发性？事务隔离级别，每个级别会导致什么问题，MySQL默认是哪个级别？

理论上来说，事务之间应该是完全隔离的，以避免并发事务带来的问题。然而，这将对性能产生很大影响，因为事务必须按顺序运行。在实际开发中，为了提高性能，事务会运行在较低的隔离级别上，可以通过isolate事务属性来指定事务的隔离级别。

2.1 事务并发问题

（1）脏读：事务A读取了事务B更新的数据，然后B回滚了操作，那么A读到的数据就是脏数据

（2）不可重复读：事务A多次读取相同的数据，事务B在事务A的多次读取过程中更新并提交数据。因此，当事务A多次读取相同的数据时，结果为因此该事务两次读取的数据结果会不一致。

（3）幻读：幻读解决了不可重复读的问题，保证在同一个事务中，查询结果是事务开始时的状态（一致性）。

例如：事务T1将表中所有行中的一个数据项从“1”修改为“2”。然后事务T2向表中插入一行数据项，并且该数据项的值仍然为“1”并提交到数据库。如果操作事务T1的用户查看刚刚修改的数据，会发现没有修改。事实上，这一行是从事务 T2 添加的。??这就像一个幻觉。这是幻读。

总结：不可重复读和幻读很容易混淆。不可重复读侧重于修改，而幻读侧重于添加或删除。解决不可重复读的问题只需要对符合条件的行加锁即可，而解决幻读的问题则需要对表加锁。

2.2 事务隔离级别

事务隔离级别 脏读 不可重复读 幻读

未提交读 是 是 是

不可重复读 已提交读 否 是 是

可重复读取 可重复读取 否 否 是

可序列化 否 否 否

2.3 MySQL默认的事务隔离级别是repeatable-read

2.3 补充

SQL规范中规定的标准。不同数据库的具体实现可能会有些不同。当MySQL默认的事务隔离级别为“可重复读”时，读取的行不会被锁定。

隔离级别越高，越能保证数据的完整和一致，但对并发性能的影响也越大。你不能鱼与熊掌兼得。对于大多数应用程序，可以优先将数据库系统的隔离级别设置为Read Commissed，这样可以避免脏读，并且具有更好的并发性能。虽然会导致不可重复读、幻读等并发问题，但在个别可能出现此类问题的情况下，应用程序可以使用悲观锁或乐观锁来控制。

3、MySQL中常见的三种存储引擎（InnoDB、MyISAM、MEMORY）有什么区别？

MySQL存储引擎中MyISAM和InnoDB的区别详解

blog.csdn.net/lc0817/arti…

MySQL存储引擎MyISAM和Innodb总结

……

3.1 MySQL存储引擎MyISAM和InnoDB如何选择

MySQL有多种存储引擎。每个存储引擎都有自己的优点和缺点。您可以选择最好的一种：MyISAM、InnoDB、MERGE、MEMORY (HEAP)、BDB (BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。

虽然MySQL中的存储引擎不仅仅是MyISAM和InnoDB，但常用的有两种。

两种存储引擎的一般区别如下：

3.2 关于MySQL数据库提供的两种存储引擎，选择使用MyISAM和InnoDB：

有人说MyISAM只能用于小型应用程序。其实，这只是一种偏见。如果数据量比较大，就需要通过升级架构来解决，比如分表、分库，而不是单纯依靠存储引擎。

现在普遍使用的是innodb。主要原因是MyISAM的全表锁、读写序列化问题以及表锁的并发效率问题。效率低下。 MyISAM 一般不用于读写密集型应用程序。

3.3 MEMORY存储引擎

MEMORY是MySQL中一种特殊类型的存储引擎。它使用内存中存储的内容创建表，并且数据全部在内存中。这些功能与前两者有很大不同。

每个基于MEMORY存储引擎的表实际上对应一个磁盘文件。文件的文件名与表名相同，类型为frm类型。该文件中仅存储表的结构。数据文件全部存储在内存中，有利于数据的快速处理，提高了整个表的效率。值得注意的是，服务器需要有足够的内存来维持MEMORY存储引擎中表的使用。如果不再需要，可以释放内存，甚至删除不需要的表。

MEMORY 默认使用哈希索引。它比使用 B 树索引更快。当然，如果想使用B树索引，可以在创建索引时指定。

请注意，MEMORY 很少使用，因为它将数据存储在内存中。如果内存出现异常，数据就会受到影响。如果重新启动或关闭，所有数据都将丢失。因此，基于MEMORY的表的生命周期很短，一般都是一次性使用。

4、MySQL的MyISAM和InnoDB存储引擎的事务和锁级别是多少？它们的适用场景有哪些？

交易处理

锁定级别

5、查询语句的不同元素（where、jion、limit、group by、having等）的执行顺序是怎样的？

(1)查询中使用的关键字主要有6个，其顺序为select--from--where--group by--having--order by

其中select和from是必需的，其他关键字是可选的。这6个关键字的执行顺序与SQL语句的书写顺序并不相同。相反，它们按以下顺序执行。

（2）from后面的表关联是从右向左解析的，而where条件的解析顺序是自下而上的。

也就是说，在写SQL文本时，尽量把数据量少的表放在最右边进行关联（用小表匹配大表），把能过滤掉少量数据的条件放在where 语句中的数据。最左边（用小桌子搭配大桌子）

6.什么是临时表？临时表什么时候删除？

可以手动删除时间表：

如果存在则删除临时表 temp_tb；

复制代码

临时表仅对当前连接可见。当连接关闭时，MySQL会自动删除该表并释放所有空间。因此，不同的连接中可以创建同名的临时表，并且操作属于该连接的临时表。

创建临时表的语法与创建表的语法类似，只是增加了关键字 TEMPORARY，如：

创建临时表 tmp_table (

名称 VARCHAR (10) NOT NULL,

时间日期不为空

）；

从 tmp_table 中选择*；

7. MySQL B+Tree索引和Hash索引有什么区别？

那么为什么大家不都用Hash索引，还要用B+树索引呢？

7.1 哈希索引

(1) Hash索引只能满足“=”、“IN”和“”查询，不能使用范围查询，因为Hash值经过相应Hash算法处理后的大小关系不能保证完全一致和之前的哈希操作一样；

(2) 不能使用Hash索引来避免数据排序操作，因为Hash值的大小关系不一定与Hash操作前的键值完全相同；

(3) 不能使用部分索引键来查询Hash索引。对于组合索引来说，Hash索引在计算Hash值时，会将组合索引键进行合并，然后一起计算Hash值，而不是单独计算Hash值，因此使用组合索引的前一个。或者当查询多个索引键时，无法使用Hash索引；

(4)哈希索引任何时候都无法避免表扫描。由于不同的索引键具有相同的Hash值，即使获得满足某个Hash键值的记录条数，也无法直接从Hash索引完成查询。查询数据回表；

(5)当Hash索引遇到大量相等的哈希值时，其性能不一定会高于B+树索引。

7.2 B+树索引

在MySQL中，只有HEAP/MEMORY引擎支持Hash索引。

常用的InnoDB引擎默认使用B+树索引。它实时监控表上索引的使用情况。如果认为建立哈希索引可以提高查询效率，就会自动在内存中创建一个“自适应哈希索引缓冲区”。建立哈希索引（InnoDB 中默认启用自适应哈希索引）。通过观察搜索模式，MySQL 将使用索引键的前缀来创建哈希索引。如果表的几乎大部分都在缓冲池中，则创建哈希索引。索引可以加速等效查询。

7.3 B+树索引和哈希索引的明显区别是：

如果是等价查询，那么哈希索引显然占有绝对优势，因为只需通过一种算法就能找到对应的键值；当然，这个前提是键值都是唯一的。如果key值不唯一，则需要先找到key的位置，然后根据链表向后扫描，直到找到对应的数据；

如果是范围查询检索，这时候哈希索引就没用了，因为原本有序的键值经过哈希算法后可能会变得不连续，没有办法用索引来补全范围。查询检索；

同理，哈希索引无法使用索引来完成排序，以及像‘xxx%’这样的部分模糊查询（这种部分模糊查询本质上其实是范围查询）；

哈希索引也不支持多列联合索引的最左匹配规则；

B+树索引的关键字检索效率比较平均，不像B树那样波动那么大。当存在大量重复键值时，由于所谓的哈希冲突问题，哈希索引的效率也极低。

大多数场景都会有范围查询、排序、分组等查询功能，B+树索引就足够了。

8. SQL查询语句确定创建什么类型的索引？如何优化查询？

9. 聚集索引和非聚集索引有什么区别？

聚集索引/非聚集索引

根本区别

聚集索引和非聚集索引的根本区别在于表记录的顺序与索引的顺序是否一致。

9.1聚集索引

聚集索引表记录的排序顺序与索引的排序顺序一致，因此查询效率快。只要找到第一个索引值记录，剩余的连续记录也在物理上连续存储。聚集索引相应的缺点就是修改速度慢，因为为了保证表中记录的物理顺序和索引顺序一致，在插入记录时会重新排序数据页。

聚集索引类似于用拼音在新华字典中查找汉字。拼音检索表和秘书顺序是按照a~z排列的，就像逻辑顺序和物理顺序一样。当你需要查找“a”和“ai”的两个发音时，当你想一次性查找“sha”的多个同音字时，你可以翻几页或者跳到下一行即可得到结果。

9.2 非聚集索引

非聚集索引制定了表中记录的逻辑顺序，但物理记录和索引不一定一致。两个索引都使用B+树结构。非聚集索引的叶子层不与实际数据页重叠，而是使用叶子层。包含指向数据页中表中记录的指针。非聚集索引层次多，不会造成数据重排。

非聚集索引类似于新华字典中通过部首查询汉字。检索表可以水平、垂直和撇号排列。不过，由于文字是按a~z的拼音顺序排列的，所以与物理地址中的逻辑地址并不对应。同时适用的情况是分组、大量不同值以及频繁更新的列。这些情况都不适合聚集索引。

10. 锁有哪些类型（乐观锁和悲观锁）？选择时如何添加排它锁？

10.1 悲观锁（Pessimistic Lock）

悲观锁的特点是先获取锁，然后再进行业务操作。即“悲观地”认为获取锁失败的可能性很大，所以在进行业务操作之前首先要保证获取锁成功。通常所说的“一锁、两检查、三更新”就是指悲观锁的使用。一般来说，对数据库的悲观锁需要数据库本身的支持，即通过常用的select...for update操作来实现悲观锁。当数据库执行select for update时，会获取selection中数据行的行锁。因此，如果其他并发执行的select for update尝试选择同一行，就会发生排除（需要等待行锁释放），从而达到锁的效果。 。 select for update获取的行锁会在当前事务结束时自动释放，所以必须在事务内使用。

这里需要注意的一件事是，不同的数据库对 select for update 有不同的实现和支持。例如Oracle支持select for update no wait，也就是说如果无法获得锁，会立即报错，而不是等待。 MySQL 没有没有等待。等等这个选项。 MySQL的另一个问题是，在执行select for update语句期间，所有扫描的行都会被锁定，这很容易导致问题。因此，如果在MySQL中使用悲观锁，一定要使用索引而不是全表扫描。

10.2 乐观锁

乐观锁也叫乐观并发控制，它假设多用户并发事务在处理过程中不会互相影响，每个事务可以处理它影响的那部分数据，而不产生锁。每个事务在提交数据更新之前，会在本事务读取数据后首先检查其他事务是否修改了数据。如果有其他事务的更新，则当前提交的事务将被回滚。

乐观锁的特点是先进行业务操作，不到万不得已才去拿锁。也就是说“乐观”认为获取锁大概率会成功，所以在完成业务操作后最后一步真正更新数据之后再获取锁即可。

乐观锁在数据库上的实现是完全符合逻辑的，不需要数据库的特殊支持。一般的做法是给需要锁定的数据加上版本号或者时间戳，然后实现如下：

乐观锁（向表中添加版本号字段） 这不是乐观锁的定义。在表中添加版本号是数据库实现乐观锁的一种方式。

(1) SELECT 数据 AS old_data, 版本 AS old_version FROM …;

(2)根据获取到的数据进行业务操作，获取new_data和new_version

(3) UPDATE SET 数据 = new_data, 版本 = new_version WHERE 版本 = old_version

if（更新行> 0）{

// 乐观锁获取成功，操作完成

} 别的 {

// 乐观锁获取失败，回滚重试

在不发生锁获取失败的情况下，乐观锁的成本比悲观锁小。但一旦发生故障，回滚的成本是比较大的。因此适合使用在获取锁失败概率比较小的场景，并且可以提高系统并发性能。

乐观锁也适用于一些特殊的场景，比如业务操作过程中无法维持与数据库的连接以及其他无法应用悲观锁的地方。

10.3 总结

悲观锁和乐观锁是数据库用来保证数据并发、防止更新丢失的两种方法。例如，在 select...for update 之前添加事务可以防止更新丢失。大多数场景下悲观锁和乐观锁没有什么区别。在一些独特的场景中存在一些差异。一般来说，我们可以从以下几个方面来判断。