一、什么是回表查询？如何避免回表查询？

索引有两种类型，一种是基于表的主键建立的主键索引，另一种是基于普通列建立的普通索引（或二级索引）。主键索引和普通索引的查询过程和查询性能是不一样的。

普通索引的叶子节点除了索引数据本身外，仅只存储主键 id 值，而主键索引的叶子节点存储的是整条数据。当使用普通索引查询某个列时，这个列未保存在这个普通索引树中时，就需要再通过主键索引树定位到相应的记录，取得对应的数据，这就是回表。因此，使用普通索引查询数据可能会存在回表的情况，在能得知 id 的前提下，尽量直接使用主键索引查询数据。

使用覆盖索引可以避免回表查询，提高查询性能。
所谓覆盖索引，指的就是普通索引中存储的列足以返回查询想要的数据。为了达到这个目的，可以适当增加普通索引中存储的列，也就是使用组合索引，将多个列值联合组成一个索引。例如，(a, b, c) 三个列的组合索引，如果select的数据已经在这三列中，那么就不需要回表查询了。

二、为什么MySQL建议使用自增主键？什么是代理主键、业务主键？

代理主键，就是无意义的自增 id。自然主键，即业务主键，就是业务相关的编号，例如身份证、订单号这类。
1、业务主键更浪费空间。
2、业务主键无序，写入时需更长时间组织索引。为了使主键有序，需要进行索引重排，无序的编号需要频繁进行索引重排，降低入库性能（数据移动），而代理主键本身自增，不需要进行索引重排。
3、业务主键如果是字符串，在分库分表时，无法直接取模运算，需要先转换数字，处理更耗时。
4、业务主键在分布式系统中存在高耦合问题，一旦数据本身发生变化，系统极难维护。例如，用户系统、积分系统、账户系统（管理余额），如果用户系统以身份证作为主键，在系统间操作的时候需要传入这个主键，但如果是一个老人，身份证15位，而现在国家要求身份证必须更改为18位，其他系统都需要进行相应的更新，极大的增加了数据维护成本，系统之间耦合度太高。
5、业务主键可能存在冲突。例如如果是以身份证为id，那么在一个员工表中，假设一个员工离职，后因为某种原因又入职，一般的业务处理都是重新创建一条员工记录，但身份证号相同，就会存在主键冲突的问题。
6、如果没有指定自增id 主键，那么该表的第一个唯一非空索引被作为聚集索引。如果这个列是 char 类型的数据，会增加表的插入开销。
7、如果没有指定自增 id，也没有唯一非空索引，那么mysql就会自动生成一个隐藏的主键作为聚集索引，这个隐藏的主键是一个6个字节的列，这个列值也是自增的。

三、为什么MySQL建议单表不超过2000W数据？

InnoDB的B+树可以存放多少数据？答案是：约2千万。
这个数字如何计算？
计算机存储数据的最小单元是扇区，一个扇区的大小是512字节；文件系统的最小存储单元是4K；InnoDB的最小存储单元是页（Page），大小是16K。
因此，InnoDB的数据文件 .ibd 文件的大小始终是 16K的整数倍。
表中的数据都存储在页中，假设一条数据大小为1K，那么一页就可以存储16条数据，它既可以存放数据，也可以存放键值+指针。在B+树中，叶子节点用页来存放数据，非叶子节点来存放键值+指针。
索引组织表通过非叶子节点的二分查找，以及指针确定数据在哪个页中，进而再去数据页查找需要的数据。
假设 B+ 树高为 2，即存在一个根节点和若干个叶子节点，那么这颗 B+树的存放总记录数为：

根节点指针数 × 单个叶子节点记录行数

假设一行数据 1K，一页存16行（这里假设一行记录的数据大小是1K，实际上现在很多互联网业务数据大小通常就是 1K左右）。
假设主键使用bigint类型，长度为 8 字节，而指针大小在InnoDB 源码中为 6 字节，所以，存储键值+指针的非叶子节点（页）能存储：16K÷(8 + 6) = 16384 / 14 = 1170。

高度为 2 的B+树，根节点可以存储1170个索引+指针，每个叶子节点可以存放 16 行数据，那么这个 B+ 树最多可以容纳的数据行数为：

1170 × 16 = 18720

以此算法计算高度为 3 的 B+ 树，无非多了一层非叶子节点，容易得到下面的计算公式：

1170 × 1170 × 16 = 21902400 ≈ 2 千万

所以在 InnoDB 中 B+ 树高度一般为 2 ~ 3层，就能够满足千万级的数据存储。在查找数据时，一次页的查找代表一次IO，通过主键索引查询通常只需要 1 ~ 3次IO 操作即可查找到数据。

四、MySQL自增id用完了怎么办？

我们一般在设计表的时候，会给表设置一个自增id。这个自增id是表级别的，每当我们要插入数据的时候会取得表的最大id并加一就是新数据的id。id的类型一般是 int，也有例如 tinyint。以无符号的tinyint 为例，它的最大值是2^8 - 1=255，那么当表中已经有255条记录之后，再新增数据就会报主键冲突。

而另一种情况，如果没有为数据表设置主键，mysql会自动给表设置一个默认自增 row_id，这个row_id 最大可以达到 2^48 - 1。同样，当我们把最大的 row_id 用完，并不会报主键冲突，而是会从最小值开始从头开始，进而覆盖掉老数据，这个是个比较严重的问题，除非表中数据是类似日志这种允许擦除老数据。

五、MySQL自增主键是连续的吗？

MySQL自增主键不是连续的。就算步长为1，但也一定会出现空档的情况。
表的结构定义存放在后缀名为 .frm 的一个文件中，但它不会保存这个主键的自增值。不同的存储引擎对于自增主键的保存策略也有所不同。
自增 id 是如何存储的？
InnoDB 在MySQL 5.7 以前，主键的自增值（即最大的那个主键值）是保存在内存中的，并未持久化。每次重启mysql之后，第一次打开这个表，mysql都会去扫描这个表，找到最大id，然后加上步长（默认就是1）作为这个自增值保留在内存中。8.0 之后，增加了自增值持久化的能力，如果mysql突然宕机，重启后也可以从磁盘直接取得自增值，而不需要扫描，实际上是存储在 redo log 文件中。
MyISAM 是将自增值存储在数据文件中的。

自增策略是怎样的？
自增主键的自增策略是，默认情况下可以自增加一，但这种情况仅是当前我们未指定 id 字段的情况，如果有显式指定，例如，当前自增值为 x，此时插入一条数据，指定 id = y ( y > x)，那么自增值就会更新成 y；如果 y < x，首先会判断是否冲突，若不冲突，自增值不会改变，依然是 x。

出现自增值不连续的情况：
1、唯一键冲突（注意不是主键冲突），插入失败，浪费自增资源。例如两个事务，A事务申请 id + 1，B事务申请 id + 2，但是A事务中包含的唯一键与表中某个唯一键冲突，导致插入失败，浪费了 id + 1这个资源，就会产生不连续的情况。
2、事务回滚。事务回滚不会恢复申请的自增资源。
3、对于批量插入的数据，id 自增会是上次的两倍。

为什么这些场景下不会恢复自增 id ？
如果要恢复为使用的自增id，例如插入失败，自增id不变，那么就必须增加相应的同步机制。例如并发场景下，例如给自增值加锁，并发请求时，必须等待前面的 insert 语句成功后，才取得自增值；要么使用判断的方式，循环判断前面的 insert 是否插入了新的自增值，才使用最新的自增值。不管是悲观锁还是乐观锁，都势必会降低入库性能。因此从性能角度来考虑，自增id浪费了就浪费了。

六、一条SQL语句在MySQL中是如何执行的？

首先，需要了解MySQL的层次结构。

1. 连接层：最上层是一些客户端和连接服务。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
2. 服务层：第二层服务层，主要完成大部分的核心服务功能， 包括查询解析、分析、优化、缓存、以及所有的内置函数，所有跨存储引擎的功能也都在这一层实现，包括触发器、存储过程、视图等。
3. 引擎层：第三层存储引擎层，存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取
4. 存储层：第四层为数据存储层，主要是将数据存储在运行于该设备的文件系统之上，并完成与存储引擎的交互。

SQL 语句的执行流程如下：

客户端请求 —> 连接器（验证用户身份，给予权限） —> 查询缓存（存在缓存则直接返回，不存在则执行后续操作） —> 分析器（对SQL进行词法分析和语法分析操作） —> 优化器（主要对执行的sql优化选择最优的执行方案方法） —> 执行器（执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口） —> 去引擎层获取数据返回（如果开启查询缓存则会缓存查询结果）

(图片来源：https://zhuanlan.zhihu.com/p/164519371)

七、MySQL的存储引擎区别？

1、InnoDB 支持事务，MyISAM 不支持事务，这也是 MySQL 将默认存储引擎从 MyISAM 变为 InnoDB 的重要原因之一。
2、InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MyISAM 会失败。
3、InnoDB 使用聚集索引，MyISAM 是非聚集索引。
聚集索引的数据文件存放在主键索引的叶子节点上，因此InnoDB必须要有主键，通过主键搜索效率更高。MyISAM 的索引与数据分离，是非聚集索引，不论是主键还是普通索引，它们与数据文件都是分离的。
4、InnoDB 不保存表的具体行数，执行 select count(*) 需要全表扫描，而 MyISAM 用一个变量保存整张表的行数，速度更快。多说两句，InnoDB 执行 select count(*) 时，会先把数据读出来，一行一行累加，最后返回总数据。所以，当数据越来越大时，语句就越来越耗时，但由于 InnoDB 自身的事务特点，即 MVCC 的原因，InnoDB 表很难知道数据总数。
5、InnoDB 最小的锁粒度是行锁，MyISAM 仅支持表锁，在并发访问的情况下效率太低。