30道MySQL高频面试题解析，让你面试少走99%的弯路！！

前言

整理了最新mysql面试题合集

MySQL的逻辑架构

2.架构图

MySQL的逻辑架构大致可以分为三层：

• 第一层：处理客户端连接、授权认证，安全校验等。
• 第二层：服务器server层，负责对SQL解释、分析、优化、执行操作引擎等。
• 第三层：存储引擎，负责MySQL中数据的存储和提取。

我们要知道MySQL的服务器层是不管理事务的，事务是由存储引擎实现的，而MySQL中支持事务的存储引擎又属InnoDB使用的最为广泛，所以后续文中提到的存储引擎都以InnoDB为主。

上边这张图， 她是MySQL更新数据的基础流程，其中包括​​redo log、bin log、undo log​​三种日志间的大致关系，好了闲话少说直奔主题。

3. 日志介绍

一、mysql 存储引擎

1. 存储引擎是什么

MySQL5.5之前，默认引擎是“MyISAM”；
从MySQL5.5版本开始，默认引擎是“InnoDB”，该引擎完全支持符合ACID和事务，支持外键、提交、回滚、前滚操作，表的大小最高可达64TB。在MySQL中，可以使用“SHOW
ENGINES;”命令查看系统所支持的引擎类型以及默认引擎；输出结果中，DEFAULT关键字标识的引擎就是当前默认的存储引擎。

• 数据库存储引擎是​​数据库底层软件组件​​，数据库管理系统使用数据引擎进行创建、查询、更新和删除数据操作。简而言之，​​存储引擎就是指表的类型​​。
• 数据库的存储引擎决定了表在计算机中的存储方式。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎还可以获得特定的功能。
• MySQL为其表提供各种存储引擎，如InnoDB、MyISAM、Memory、Merge、Archive、CSV、BLACKHOLE 等。
• 可以使用SHOW ENGINES;语句查看系统所支持的引擎类型，结果如图所示。
  
• Support 列的值表示某种引擎是否能使用，YES表示可以使用，NO表示不能使用，DEFAULT表示该引擎为当前默认的存储引擎。

可以看出，当前默认的存储引擎是InnoDB。

2. 各种存储引擎的介绍

MyISAM 引擎

• MyISAM扩展了以前的ISAM存储引擎。MyISAM表针对压缩和速度进行了优化。MyISAM表也可以在平台和操作系统之间移植。
  MyISAM表的大小可以达到256TB，这是巨大的。此外，MyISAM表可以压缩为只读表以节省空间。在启动时，MySQL会检查MyISAM表是否存在损坏，甚至在出现错误时对其进行修复。MyISAM表不是事务安全的。

InnoDB 引擎

• InnoDB表完全支持符合ACID和事务。它们也是性能的最佳选择。InnoDB表支持外键，提交，回滚，前滚操作。InnoDB表的大小最高可达64TB。
  与MyISAM一样，InnoDB表可在不同平台和操作系统之间移植。如有必要，MySQL还会在启动时检查和修复InnoDB表。

MERGE 引擎

• MERGE表是一个虚拟表，它将多个MyISAM表组合在一起，这些表具有与一个表类似的结构。MERGE存储引擎也称为MRG_MyISAM引擎。MERGE表没有自己的索引; 它使用组件表的索引。
• 使用MERGE表，可以在连接多个表时加快性能 。MySQL只允许您对MERGE表执行SELECT，DELETE，UPDATE和INSERT操作。如果DROP TABLE在MERGE表上使用MERGE语句，则仅删除规范。基础表不会受到影响。

Memory 引擎

• 内存表存储在内存中并使用哈希索引，因此它们比MyISAM表更快。内存表数据的生命周期取决于数据库服务器的正常运行时间。内存存储引擎以前称为HEAP。

Archive 引擎

• 归档存储引擎允许您将大量记录（用于归档）存储为压缩格式以节省磁盘空间。存档存储引擎在插入时压缩记录，并在读取时使用zlib库对其进行解压缩。
  归档表仅允许INSERT和SELECT语句。ARCHIVE表不支持索引，因此需要对表读取行进行全表扫描。

CSV

• CSV存储引擎以逗号分隔值（CSV）文件格式存储数据。CSV表提供了一种将数据迁移到非SQL应用程序（如电子表格软件）的便捷方法。
  CSV表不支持NULL数据类型。此外，读取操作需要全表扫描。

FEDERATED

• FEDERATED存储引擎可让您无需使用群集或复制技术管理从远程MySQL服务器的数据。本地联合表不存储任何数据。从本地联合表查询数据时，将从远程联合表中自动提取数据。

二、mysql 日志

1. 日志的种类

MySQL中有八种日志文件，分别是：

• ​​重做日志（redo log）​​，
• 回滚日志（undo log）​​，
• ​​二进制日志（binlog）​​，
• 错误日志（errorlog），
• 慢查询日志（slow query log），
• 一般查询日志（general log），
• 中继日志（relay log），
• DDL日志 （metadata log），
  他们分别都有各自的作用，而且默认情况下，服务器的日志文件都位于数据目录（datadir）中。

2. 重点日志种类介绍

a、重做日志（redo log）

作用：
确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

内容：

物理格式的日志，记录的是物理数据页面的修改的信息，其redo log是顺序写入redo log file的物理文件中去的。

什么时候产生：

事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。

什么时候释放：

当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

对应的物理文件：

默认情况下，对应的物理文件位于数据库的data目录下的 ib_logfile1&ib_logfile2

innodb_log_group_home_dir 指定日志文件组所在的路径，默认./ ，表示在数据库的数据目录下。
innodb_log_files_in_group 指定重做日志文件组中文件的数量，默认2

关于文件的大小和数量，由以下两个参数配置：

innodb_log_file_size 重做日志文件的大小。 innodb_mirrored_log_groups
指定了日志镜像文件组的数量，默认1

其他：

很重要一点，redo log是什么时候写盘的？前面说了是在事物开始之后逐步写盘的。
之所以说重做日志是在事务开始之后逐步写入重做日志文件，而不一定是事务提交才写入重做日志缓存，原因就是，重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为8M(这里设置的16M),Innodb存储引擎先将重做日志写入innodb_log_buffer中。

然后会通过以下三种方式将innodb日志缓冲区的日志刷新到磁盘

Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件。
每个事务提交时会将重做日志刷新到重做日志文件。

当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件

由此可以看出，重做日志通过不止一种方式写入到磁盘，尤其是对于第一种方式，Innodb_log_buffer到重做日志文件是Master Thread线程的定时任务。

因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。

即使某个事务还没有提交，Innodb存储引擎仍然每秒会将重做日志缓存刷新到重做日志文件。

这一点是必须要知道的，因为这可以很好地解释再大的事务的提交（commit）的时间也是很短暂的。

b、 回滚日志（undo log）

作用：

保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读

内容：

逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。

什么时候产生：

事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性

什么时候释放：

当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。

对应的物理文件：

MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中。
MySQL5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数

如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。

关于MySQL5.7之后的独立undo 表空间配置参数如下：

innodb_undo_directory = /data/undospace/ –undo独立表空间的存放目录
innodb_undo_logs = 128 –回滚段为128KB innodb_undo_tablespaces = 4
–指定有4个undo log文件

如果undo使用的共享表空间，这个共享表空间中又不仅仅是存储了undo的信息，共享表空间的默认为与MySQL的数据目录下面，其属性由参数innodb_data_file_path配置。

其他：
undo是在事务开始之前保存的被修改数据的一个版本，产生undo日志的时候，同样会伴随类似于保护事务持久化机制的redolog的产生。

默认情况下undo文件是保持在共享表空间的，也即ibdatafile文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的undo信息，全部保存在共享表空间中的。

因此共享表空间可能会变的很大，默认情况下，也就是undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。

因此，mysql5.7之后的“独立undo 表空间”的配置就显得很有必要了。

c、二进制日志（binlog）

作用：

用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。
用于数据库的基于时间点的还原。

内容：

逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。

但又不完全