MySQL面试题（无答案版） 中高级必看

1、mysql记录存储：mysql的数据是怎么组织的

2、页内记录的维护（顺序保证/插入策略/页内查询）

3、MySQL内存管理（页面管理、页面淘汰、LRU）:全表扫描对内存有什么影响? 如何避免热数据被淘汰? 没有空闲页怎么办？

4、InnoDB 加锁的过程是如何实现的？常见锁问题有那些？

5、MVCC是什么？如何实现多版本控制？如何解决写冲突？

6、回滚日志Undo log如何实现多版本控制与保证事务的原子性？

7、undo log如何清理，为何InnoDB select count(*)  这么慢？

8、重做日志Redo log如何实现事务持久性？

9、InnoDB行级锁、间隙锁、表级锁如何实现的？

10、InnoDB加锁过程如何实现的？

11、海量数据下 主键如何设计？

12、聚集索引、二级索引与联合索引具备哪些特点？

13、在进行索引优化时应该注意哪些问题/

14、MySQL如何进行库表的优雅设计？

15、如何实现数据备份之延时库部署

16、MySQL如何高效实现数据冗余部署

17、MySQL高可用方案有哪些

MySQL选了个不恰当索引而导致的慢查询。

某晚收到了线上数据库的频繁报警，数据库突然大量慢查询，导致每个数据库连接执行一个慢查询都要耗费很久。这还导致突然过来的很多查询需要让MySQL开辟更多连接，因此报警也告诉我们，数据库的连接剧增，而且每个连接都打满，每个连接都要执行一个慢查询。

接着DB的连接全部打满，无法开辟新连接，但还持续的有新的查询请求，导致DB无法处理新查询，很多查询发到DB直接就阻塞然后超时，导致商品系统频繁的报警，出现大量DB查询超时报错的异常。

这意味着商品数据库及商品系统濒临崩溃，大量慢查询耗尽DB连接资源，而且一直阻塞在数据库里执行，数据库没法执行新的查询，商品数据库无法执行查询，用户没法使用商品系统，也就没法查询和筛选电商网站里的商品了。

报警时机又正是晚高峰，虽说商品数据有多级缓存架构，但下单过程中，还是会大量请求商品系统，所以晚高峰时，商品系统本身TPS大致几千。因此发现数据库的监控里显示每min的慢查询超过10w+：商品系统大量的查询都变成了慢查询。

慢查询主要就是如下语句：

该语句执行的商品表里大致1亿左右数据量，该量级已稳定很长时间，主要也就是这么多商品，但上面语句居然一执行就是几十s！基本上数据库的连接全部被慢查询打满，一个连接要执行几十s的SQL，然后才能执行下一个SQL，此时数据库基本就废了，没法执行什么查询。所以商品系统本身也报警查询数据库的超时异常。

经常用到的查询字段肯定都建了索引，即index_category(catetory,sub_category)肯定存在。因为如果你一旦用上了品类索引，按品类和子类去在索引里筛选：

理论上执行速度很快，即使表有亿级数据，但也不应超过1s。但跑了几十秒，说明肯定没用那个索引，看执行计划：

possible_keys=index_category的，key=PRIMARY，Extra=Using where

就是在扫描主键索引，还用where条件里的两个字段做筛选，所以这么扫描就会耗费几十s。

为快速解决问题，使用force index语法，强制改变MySQL自动选择不恰当聚簇索引进行扫描的行为：

再次执行SQL，仅耗费100多ms。

所以若MySQL使用了错误的执行计划，那就force index语法改变它。

但案例还有问题：

该表是个亿级数据量大表，那index_category二级索引也比较大，所以此时MySQL觉得如果从index_category二级索引查找符合where条件的一波数据，接着还得回表。因为要select *，所以必然涉及回表，但在回表前，必然要做完order by id desc limit xx,xx *** 作。

举个例子，根据where category='xx' and sub_category='xx'，从index_category二级索引里查找出一波数据，假设几万条，

因为二级索引包含主键id，就得按order by id desc，对这几万条数据基于临时磁盘文件进行filesort磁盘排序，排序后，再按limit xx,xx语法将指定位置的几条数据拿出来，假设limit 0,10，那么就是把10条数据拿出来。拿出来10条数据之后，再回到聚簇索引根据id查，把这10条数据的完整字段都查出来，这就是MySQL认为如果你使用index_category的话，可能会发生的一个情况。

所以他担心，你根据

从index_category二级索引里查出来的数据太多了，还得在临时磁盘里排序，可能性能很差，因此MySQL就把这种方式判定不太好。

因此他选择直接扫描主键的聚簇索引，因为聚簇索引按id值有序，所以扫描时，直接按order by id desc倒序得顺序扫描即可，然后因为他知道你是

也就知道你仅仅只要拿到10条数据就行了。所以他在按序扫描聚簇索引时，就会对每条数据都采用Using where，跟

条件进行比对，符合条件的就直接放入结果集里去，最多就是放10条数据进去就可以返回了。

此时MySQL认为，按顺序扫描聚簇索引，拿到10条符合where条件的数据，应该很快，很可能比使用index_category二级索引更快，因此此时他就采用了扫描聚簇索引的这种方式。

这SQL之前在线上系统运行一直没问题，即之前在线上系统而言，即使采用扫描聚簇索引，该SQL也确实运行不慢，最起码是不会超过1s。

为何突然大量报慢查询，耗时几十s？因为之前

条件通常有返回值，即根据条件里的取值，扫描聚簇索引，通常都是很快就能找到符合条件的值并返回，所以之前其实性能也没啥问题。

但后来可能是商品系统里的运营人员，在商品管理的时候加了几种商品分类和子类，但是这几种分类和子类的组合其实没有对应的商品，导致很多用户使用这种分类和子类去筛选商品

条件实际上是查不到任何数据的！所以扫描聚簇索引时，怎么都扫不到符合条件的结果，一下就把聚簇索引全部扫了一遍，等于上亿数据全表扫描一遍，都没找到符合where category='新分类' and sub_category='新子类'这个条件的数据。

正因如此，才导致这个SQL语句频繁的出现几十秒的慢查询，进而导致MySQL连接资源打满，商品系统崩溃！

SQL调优并不太难，核心是看懂SQL执行计划，理解慢的原因，然后想法解决，本案例就得通过force index语法来强制某个SQL用我们指定的索引。

篇幅所限本文只写了MySQL25题，像其他的Redis，SSM框架，算法，计网等技术栈的面试题后面会持续更新，个人整理的1000余道面试八股文会放在文末给大家白嫖，最近有面试需要刷题的同学可以直接翻到文末领取。

如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如果使用非自增主键（如果身份z号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置， 频繁的移动、分页 *** 作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE（optimize table）来重建表并优化填充页面。

Server层按顺序执行sql的步骤为：

简单概括：

可以分为服务层和存储引擎层两部分，其中：

服务层包括连接器、查询缓存、分析器、优化器、执行器等 ，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

存储引擎层负责数据的存储和提取 。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认的存储引擎。

Drop、Delete、Truncate都表示删除，但是三者有一些差别：

Delete 用来删除表的全部或者一部分数据行，执行Delete之后，用户需要提交(commmit)或者回滚(rollback)来执行删除或者撤销删除，会触发这个表上所有的delete触发器。

Truncate 删除表中的所有数据，这个 *** 作不能回滚，也不会触发这个表上的触发器，TRUNCATE比Delete更快，占用的空间更小。

Drop 命令从数据库中删除表，所有的数据行，索引和权限也会被删除，所有的DML触发器也不会被触发，这个命令也不能回滚。

因此，在不再需要一张表的时候，用Drop；在想删除部分数据行时候，用Delete；在保留表而删除所有数据的时候用Truncate。

隔离级别脏读不可重复读幻影读 READ-UNCOMMITTED 未提交读READ-COMMITTED 提交读REPEATABLE-READ 重复读SERIALIZABLE 可串行化读

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ （可重读）

这里需要注意的是 ：与 SQL 标准不同的地方在于InnoDB 存储引擎在 REPEATABLE-READ（可重读）事务隔离级别 下使用的是 Next-Key Lock 锁 算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以 说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读） 已经可以完全保证事务的隔离性要 求，即达到了 SQL标准的SERIALIZABLE(可串行化)隔离级别。

因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内 容):，但是你要知道的是InnoDB 存储引擎默认使用 REPEATABLE-READ（可重读）并不会有任何性能损失 。

InnoDB 存储引擎在分布式事务 的情况下一般会用到SERIALIZABLE(可串行化)隔离级别。

主要原因：B+树只要遍历叶子节点就可以实现整棵树的遍历，而且在数据库中基于范围的查询是非常频繁的，而B树只能中序遍历所有节点，效率太低。

文件与数据库都是需要较大的存储，也就是说，它们都不可能全部存储在内存中，故需要存储到磁盘上。而所谓索引，则为了数据的快速定位与查找，那么索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数，因此B+树相比B树更为合适。数据库系统巧妙利用了局部性原理与磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入，而红黑树这种结构，高度明显要深的多，并且由于逻辑上很近的节点(父子)物理上可能很远，无法利用局部性。

最重要的是，B+树还有一个最大的好处：方便扫库。

B树必须用中序遍历的方法按序扫库，而B+树直接从叶子结点挨个扫一遍就完了，B+树支持range-query非常方便，而B树不支持，这是数据库选用B+树的最主要原因。

B+树查找效率更加稳定，B树有可能在中间节点找到数据，稳定性不够。

B+tree的磁盘读写代价更低：B+tree的内部结点并没有指向关键字具体信息的指针(红色部分)，因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一块盘中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多，相对来说IO读写次数也就降低了；

B+tree的查询效率更加稳定：由于内部结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引，所以，任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当；

视图是一种虚拟的表，通常是有一个表或者多个表的行或列的子集，具有和物理表相同的功能 游标是对查询出来的结果集作为一个单元来有效的处理。一般不使用游标，但是需要逐条处理数据的时候，游标显得十分重要。

而在 MySQL 中，恢复机制是通过回滚日志（undo log）实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后在对数据库中的对应行进行写入。当事务已经被提交之后，就无法再次回滚了。

回滚日志作用：1)能够在发生错误或者用户执行 ROLLBACK 时提供回滚相关的信息 2) 在整个系统发生崩溃、数据库进程直接被杀死后，当用户再次启动数据库进程时，还能够立刻通过查询回滚日志将之前未完成的事务进行回滚，这也就需要回滚日志必须先于数据持久化到磁盘上，是我们需要先写日志后写数据库的主要原因。

InnoDB

MyISAM

总结

数据库并发会带来脏读、幻读、丢弃更改、不可重复读这四个常见问题，其中：

脏读 ：在第一个修改事务和读取事务进行的时候，读取事务读到的数据为100，这是修改之后的数据，但是之后该事务满足一致性等特性而做了回滚 *** 作，那么读取事务得到的结果就是脏数据了。

幻读 ：一般是T1在某个范围内进行修改 *** 作（增加或者删除），而T2读取该范围导致读到的数据是修改之间的了，强调范围。

丢弃修改 ：两个写事务T1 T2同时对A=0进行递增 *** 作，结果T2覆盖T1，导致最终结果是1 而不是2，事务被覆盖

不可重复读 ：T2 读取一个数据，然后T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

第一个事务首先读取var变量为50，接着准备更新为100的时，并未提交，第二个事务已经读取var为100，此时第一个事务做了回滚。最终第二个事务读取的var和数据库的var不一样。

T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

T1 和 T2 两个事务都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。例如：事务1读取某表中的数据A=50，事务2也读取A=50，事务1修改A=A+50，事务2也修改A=A+50，最终结果A=100，事务1的修改被丢失。

T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

悲观锁，先获取锁，再进行业务 *** 作，一般就是利用类似 SELECT … FOR UPDATE 这样的语句，对数据加锁，避免其他事务意外修改数据。当数据库执行SELECT … FOR UPDATE时会获取被select中的数据行的行锁，select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。

乐观锁，先进行业务 *** 作，只在最后实际更新数据时进行检查数据是否被更新过。Java 并发包中的 AtomicFieldUpdater 类似，也是利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，来实现乐观锁需要的版本判断。

分库与分表的目的在于，减小数据库的单库单表负担，提高查询性能，缩短查询时间。

通过分表 ，可以减少数据库的单表负担，将压力分散到不同的表上，同时因为不同的表上的数据量少了，起到提高查询性能，缩短查询时间的作用，此外，可以很大的缓解表锁的问题。分表策略可以归纳为垂直拆分和水平拆分:

水平分表 ：取模分表就属于随机分表，而时间维度分表则属于连续分表。如何设计好垂直拆分，我的建议：将不常用的字段单独拆分到另外一张扩展表. 将大文本的字段单独拆分到另外一张扩展表, 将不经常修改的字段放在同一张表中，将经常改变的字段放在另一张表中。对于海量用户场景，可以考虑取模分表，数据相对比较均匀，不容易出现热点和并发访问的瓶颈。

库内分表 ，仅仅是解决了单表数据过大的问题，但并没有把单表的数据分散到不同的物理机上，因此并不能减轻 MySQL 服务器的压力，仍然存在同一个物理机上的资源竞争和瓶颈，包括 CPU、内存、磁盘 IO、网络带宽等。

分库与分表带来的分布式困境与应对之策 数据迁移与扩容问题----一般做法是通过程序先读出数据，然后按照指定的分表策略再将数据写入到各个分表中。分页与排序问题----需要在不同的分表中将数据进行排序并返回，并将不同分表返回的结果集进行汇总和再次排序，最后再返回给用户。

不可重复读的重点是修改，幻读的重点在于新增或者删除。

视图是虚拟的表，与包含数据的表不一样，视图只包含使用时动态检索数据的查询；不包含任何列或数据。使用视图可以简化复杂的 sql *** 作，隐藏具体的细节，保护数据；视图创建后，可以使用与表相同的方式利用它们。

视图不能被索引，也不能有关联的触发器或默认值，如果视图本身内有order by 则对视图再次order by将被覆盖。

创建视图：create view xxx as xxxx

对于某些视图比如未使用联结子查询分组聚集函数Distinct Union等，是可以对其更新的，对视图的更新将对基表进行更新；但是视图主要用于简化检索，保护数据，并不用于更新，而且大部分视图都不可以更新。

B+tree的磁盘读写代价更低，B+tree的查询效率更加稳定 数据库索引采用B+树而不是B树的主要原因：B+树只要遍历叶子节点就可以实现整棵树的遍历，而且在数据库中基于范围的查询是非常频繁的，而B树只能中序遍历所有节点，效率太低。

B+树的特点

在最频繁使用的、用以缩小查询范围的字段,需要排序的字段上建立索引。不宜：1）对于查询中很少涉及的列或者重复值比较多的列 2）对于一些特殊的数据类型，不宜建立索引，比如文本字段（text）等。

如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称 之为“覆盖索引”。

我们知道在InnoDB存储引 擎中，如果不是主键索引，叶子节点存储的是主键+列值。最终还是要“回表”，也就是要通过主键再查找一次,这样就 会比较慢。覆盖索引就是把要查询出的列和索引是对应的，不做回表 *** 作！

举例 ：

学号姓名性别年龄系别专业 20020612李辉男20计算机软件开发 20060613张明男18计算机软件开发 20060614王小玉女19物理力学 20060615李淑华女17生物动物学 20060616赵静男21化学食品化学 20060617赵静女20生物植物学

主键为候选键的子集，候选键为超键的子集，而外键的确定是相对于主键的。

---