面试篇：MySQL
一、如何定位慢查询
1、慢查询原因：
- 聚合查询
- 多表查询
- 表数据量过大查询
- 深度分页查询
表现：页面加载慢、接口无响应，或者响应时间过长（超过1s）
2、如何定位慢查询
3、面试官：MySQL中，如何定位慢查?
- 嗯~，我们当时做压测的时候有的接口非常的慢，接口的响应时间超过了2秒以上，因为我们当时的系统部署了运维的监控系统Skywalking，在展示的报表中可以看到是哪一个接口比较慢，并且可以分析这个接口哪部分比较慢，这里可以看到SOL的具体的执行时间，所以可以定位是哪个sgl出了问题。
如果，项目中没有这种运维的监控系统，其实在MvSOL中也提供了慢日志查询的功能，可以在MvSOL的系统配置文件中开启这个慢日志的功能，并且也可以设置SOL执行超过多少时间来记录到一个日志文件中，我记得上一个项目配置的是2秒，只要SOL执行的时间超过了2秒就会记录到日志文件中，我们就可以在日志文件找到执行比较慢的SQL了。
二、sql语句执行很慢如何分析/优化
1、通过explain字段+查询语句查看索引使用情况
比如explain select * from user
- possible key 当前sql可能会使用到的索引
- key 当前sql实际命中的索引
- key len 索引占用的大小
- Extra 额外的优化建议
2、面试官：SQL语句执行很慢，如何分析？
- 如果一条sgl执行很慢的话，我们通常会使用mysql自动的执行计划explain来去查看这条sql的执行情况，比如在这里面可以通过key和key en检查是否命中了索引，如果本身已经添加了索引，也可以判断索引是否有失效的情况，第二个，可以通过type字段查看sg!是否有进一步的优化空间，是否存在全索引扫描或全盘扫描，第三个可以通过extra建议来判断，是否出现了回表的情况，如果出现了可以尝试添加索引或修改返回字段来修复 。
三、索引概念以及底层数据结构
1、什么是索引
- 索引(index)是帮助MySQL高效获取数据的数据结构(有序)
- 提高数据检索的效率，降低数据库的IO成本(不需要全表扫描)
- 通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗
2、索引的底层数据结构是什么？
MySQL的InnoDB引擎采用的B+树的数据结构来存储索引
- 阶数更多，路径更短
- 磁盘读写代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据
- B+树便于扫库和区间查询，叶子节点是一个双向链表
3、为什么选择B+树？
首先看二叉搜索树最好的情况性能是O(logn)，最坏情况是O(n)
然后来看红黑树，它的时间复杂度是O(logn)，但是在数据量特别大的时候，树会特别高，就会遍历很多层级，对性能影响较大
下来是B-Tree，B树是一种多叉路衡查找树，相对于二叉树，B树每个节点可以有多个分支，即多叉以一颗最大度数(max-degree)为5(5阶)的b-tree为例，那这个B树每个节点最多存储4个key。并且每个节点下面存储的是数据。比如20节点下方存储的是它的数据。
最后是B+树 ，B+Tree是在BTree基础上的一种优化，使其更话合实现外存储索引结构，InnoDB存储引警就是用B+Tree实现其索引结构。
与B树的区别就是非叶子节点只存储指针，不存储数据。只在叶子节点存储数据，非叶子节点作用只是导航找到叶子节点获取数据
B树与B+树对比:
- ①磁盘读写代价B+树更低：非叶子节点不存储数据，只存储指针。
- ②:查询效率B+树更加稳定：数据都存储到叶子节点，都从根开始找到叶子节点，查找路径差不多，所以效率稳定。
- ③B+树便于扫库和区间查询：底层是双向指针的链表，进行范围查询直接从叶子节点进行查询，不需要每次从根节点开始获取数据。
4、面试官：了解过索引吗? (什么是索引)
- 嗯，索引在项目中还是比较常见的，它是帮助MySOL高效获取数据的数据结构，主要是用来提高数据检索的效率，降低数据库的10成本，同时通过索引列对数据进行排序，降低数据排序的成本，也能降低了CPU的消耗
5、面试官：索引的底层数据结构了解过嘛 ?
- MySQL的默认的存储引擎InnoDB采用的B+树的数据结构来存储索引，选择B+树的主要的原因是:第一阶数更多，路径更短，第二个磁盘读写代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据，第三是B+树便于扫库和区间查询，叶子节点是一个双向链表
6、面试官：B树和B+树的区别是什么呢?
- 第一:在B树中，非叶子节点和叶子节点都会存放数据，而B+树的所有的数据都会出现在叶子节点，在查询的时候，B+树查找效率更加稳定
- 第二:在进行范围查询的时候，B+树效率更高，因为B+树都在叶子节点存储，并且叶子节点是一个双向链表
四、聚簇索引、非聚簇索引、回表查询
1、什么是聚簇索引（聚集索引），什么是非聚簇索引（二级索引），什么是回表查询？
聚集索引选取规则：
- 如果存在主键，主键索引就是聚集索引。
- 如果不存在主键，将使用第一个唯一 (UNIQUE) 索作为聚集索引
- 如果表没有主键，或没有合适的唯一索引，则lnnoDB会自动生成一个rowid作为隐藏的聚集索引
索引效果展示：
- 聚集索引：对于每个叶子节点，对应的数据就是当前聚集索引id的这一行的数据。
- 二级索引：对于每个叶子节点，对应的数据就是当前二级索引字段的id值。
- 回表查询：根据二级索引找到主键值，然后再聚集索引查询主键值叶子节点的那一行数据
2、面试官:什么是聚簇索引什么是非聚簇索引?
- 聚簇索引主要是指数据与索引放到一块，B+树的叶子节点保存了整行数据，有且只有一个,一般情况下主键在作为聚簇索引的。
- 非聚簇索引值的是数据与索引分开存储，B+树的叶子节点保存对应的主键，可以有多个，一般我们自已定义的索引都是非聚簇索引。
3、面试官:知道什么是回表查询嘛 ?
- 嗯，其实跟刚才介绍的聚簇索引和非聚簇索引是有关系的，回表的意思就是通过二级索引找到对应的主键值，然后再通过主键值找到聚集索引中所对应的整行数据，这个过程就是回表。
- [备注:如果面试官直接问回表，则需要先介绍聚簇索引和非聚簇索引]
五、覆盖索引，超大索引优化
1、什么是覆盖索引？
覆盖索引是指查询使用了索引，返回的列，必须在索引中全部能够找到
- 使用id查询，直接走聚集索引查询，一次索引扫描，直接返回数据，性能高
- 如果返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select
2、 超大分页查询
在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。
我们一起来看看执行limit分页查询耗时对比:
因为，当在进行分页查询时，如果执行 limit 9000000,10，此时需要MySQL排序前9000010 记录，仅仅返回9000000-9000010的记录，其他记录丢弃，查询排序的代价非常大。
优化思路：优化思路: 一般分页查询时，通过创建 覆盖索引 能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化。
优化前速度是11s多，这是优化后的效果
3、面试官:知道什么叫覆盖索引嘛 ?
- 覆盖索引是指select查询语句使用了索引，在返回的列，必须在索引中全部能够找到，如果我们使用id查询，它会直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。
- 如果按照二级索引查询数据的时候，返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select*，尽量在返回的列中都包含添加索引的字段。
4、面试官: MYSQL超大分页怎么处理?
- 超大分页一般都是在数据量比较大时，我们使用了limit分页查询，并且需要对数据进行排序，这个时候效率就很低，我们可以采用覆盖索引和子查询来解决。
- 先分页查询数据的id字段，确定了id之后，再用子查询来过滤，只查询这个id列表中的数据就可以了。
- 因为查询id的时候，走的覆盖索引，所以效率可以提升很多 。
六、索引创建原则
1、原则
- 针对于数据量较大，且查询比较频繁的表建立索引。单表超过10万数据(增加用户体验)
- 针对于常作为查询条件 (where)、排序 (order by)分组 (group by) 操作的字段建立索引。
- 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
- 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
- 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免,回表，提高查询效率
- 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率
- 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。
2、概括：
- 数据量较大，且查询比较频繁的表
- 常作为查询条件、排序、分组的字段
- 字段内容区分度高
- 内容较长，使用前缀索引
- 尽量联合索引
- 要控制索引的数量
- 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它
3、面试官:索引创建原则有哪些?
- 这个情况有很多，不过都有一个大前提，就是表中的数据要超过10万以上，我们才会创建索引，并且添加索引的字段是查询比较频繁的字段，一般也是像作为查询条件，排序字段或分组的字段这些。
- 还有就是，我们通常创建索引的时候都是使用复合索引来创建，一条sql的返回值，尽量使用覆盖索引，如果字段的区分度不高的话，我们也会把它放在组合索引后面的字段。
- 如果某一个字段的内容较长，我们会考虑使用前缀索引来使用，当然并不是所有的字段都要添加索引，这个索引的数量也要控制，因为添加索引也会导致新增改的速度变慢。
七、什么情况下索引会失效
1、什么情况下索引会失效
①违反最左前级法则
- 如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。
② 范围查询右边的列，不能使用索引
③不要在索引列上进行运算操作，索引将失效
④字符串不加单引号，造成索引失效
⑤类型转换会造成索引失效
⑥以%开头的Like模糊查询，索引失效。如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效
2、概括
3、面试官:什么情况下索引会失效 ?
- 嗯，这个情况比较多，我说一些自己的经验，以前遇到过的。
- 比如，索引在使用的时候没有遵循最左匹配法则，第二个是，模糊查询，如果%号在前面也会导致索引失效。如果在添加索引的字段上进行了运算操作或者类型转换也都会导致索引失效。
- 我们之前还遇到过一个就是，如果使用了复合索引，中间使用了范围查询，右边的条件索引也会失效。
- 所以，通常情况下，想要判断出这条sql是否有索引失效的情况，可以使用explain执行计划来分析 。
八、谈谈你对索引优化的经验
1、表的设计优化
- 比如设置合适的数值 (tinyint int bigint)，要根据实际情况选择
- 比如设置合适的字符串类型 (char和varchar) char定长效率高，varchar可变长度，效率稍低
2、SQL语句优化
- SELECT语句务必指明字段名称 (避免直接使用select * )
- SQL语句要避免造成索引失效的写法
- 尽量用union all代替union union会多一次过滤，效率低
- 避免在where子句中对字段进行表达式操作
- Join优化能用innerjoin 就不用left join right join，如必须使用一定要以小表为驱动内连接会对两个表进行优化，优先把小表放到外边，把大表放到里边。left join 或 right join，不会重新调整顺序
3、主从复制、读写分离
- 如果数据库的使用场景读的操作比较多的时候，为了避免写的操作所造成的性能影响 可以采用读写分离的架构。读写分离解决的是，数据库的写入，影响了查询的效率
4、概括
- 表的设计优化，数据类型的选择
- 索引优化，索引创建原则
- sql语句优化，避免索引失效，避免使用select *......
- 主从复制、读写分离，不让数据的写入，影响读操作
- 分库分表
5、面试官: sgl的优化的经验
- 嗯，这个在项目还是挺常见的，当然如果直说sgl优化的话，我们会从这几方面考虑，比如建表的时候、使用索引、sgl语句的编写、主从复制，读写分离，还有一个是如果量比较大的话，可以考虑分库分表
6、面试官:创建表的时候，你们是如何优化的呢?
- 在定义字段的时候需要结合字段的内容来选择合适的类型，如果是数值的话，像tinyint、int、bigint这些类型，要根据实际情况选择。如果是字符串类型，也是结合存储的内容来选择char和varchar或者text类型。
7、那在使用索引的时候，是如何优化呢?
- 数据量较大，且查询比较频繁的表
- 常作为查询条件、排序、分组的字段
- 字段内容区分度高
- 内容较长，使用前缀索引
- 尽量联合索引
- 要控制索引的数量
- 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它
8、面试官:你平时对sql语句做了哪些优化呢?
- 嗯，这个也有很多，比如SELECT语句务必指明字段名称，不要直接使用select*，还有就是要注意SQL语句避免造成索引失效的写法: 如果是聚合查询，尽量用union all代替union，union会多一次过滤，效率比较低;如果是表关联的话，尽量使用inmerioin，不要使用用left join right join，如必须使一定要以小表为驱动。
九、事物的特性
1、事务概念
- 事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败
2、事务的特性（ACID）
- 原子性(Atomicity) :事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
- 一致性(Consistency): 事务完成时，必须使所有的数据都保持一致状态。
- 隔离性 (Isolation)：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
- 持久性(Durability): 事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。
3、面试官:事务的特性是什么? 可以详细说一下吗?
- 嗯，这个比较清楚，ACID，分别指的是:原子性、一致性、隔离性、持久性;我举个例子，A向B转账500，转账成功，A扣除500元，B增加500元，原子操作体现在要么都成功，要么都失败在转账的过程中，数据要一致，A扣除了500，B必须增加500在转账的过程中，隔离性体现在A向B转账，不能受其他事务干扰在转账的过程中，持久性体现在事务提交后，要把数据持久化(可以说是落盘操作)。
十、并发事务问题、隔离问题
1、并发事务问题
2、隔离级别
3、面试官:并发事务带来哪些问题?
- 我们在项目开发中，多个事务并发进行是经常发生的，并发也是必然的，有可能导致一些问题
- 第一是脏读，当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
- 第二是不可重复读:比如在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
- 第三是幻读(Phantom read): 幻读与不可重复读类似。它发生在一个事务(T1) 读取了几行数据接着另一个并发事务(T2)插入了一些数据时。在随后的查询中，第一个事务(T1)就会发现多了些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。
4、面试官: 怎么解决这些问题呢? MySQL的默认隔离级别是?
- 解决方案是对事务进行隔离。
- MySQL支持四种隔离级别，分别有:
- 第一个是，未提交读(read uncommitted) 它解决不了刚才提出的所有问题，一般项目中也不用这个。第二个是读已提交(read committed)它能解决脏读的问题的，但是解决不了不可重复读和幻读第三个是可重复读(repeatable read)它能解决脏读和不可重复读，但是解决不了幻读，这个也是mysql默认的隔离级别。第四个是串行化 (serializable) 它可以解决刚才提出来的所有问题，但是由于让是事务串行执行的，性能比较低。所以，我们一般使用的都是mysql默认的隔离级别:可重复读。
十一、undo log 和redo log的区别
1、先引入缓冲池和数据页的概念
- 缓冲池(buffer pool):主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据(若缓冲池没有数据，则从磁盘加载并缓存》，以一定频率刷新到磁盘，从而减少磁盘10，加快处理速度。存储在内存结构
- 数据页(page):是InnoDB 存储引擎磁盘管理的最小单元，每个页的大小默认为 16KB。页中存储的是行数据。存储再磁盘结构
2、redo log
- 重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性
- 该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo og fle),前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中,用于在刷新脏页到磁盘,发生错误时，进行数据恢复使用。
3、undo log
回滚日志，用于记录数据被修改前的信息，作用包含两个:提供回滚和 MVVC(多版本并发控制)。undo log和redo og记录物理日志不一样，它是逻辑日志。
- 可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然
- 当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
undo log可以实现事务的一致性和原子性
4、undo log和redo log的区别
- redo log: 记录的是数据页的物理变化，服务宕机可用来同步数据
- undo log : 记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据
- redo log保证了事务的持久性undo log保证了事务的原子性和一致性
5、面试官: undo log和redo log的区别
- 好的，其中redo log日志记录的是数据页的物理变化，服务宕机可用来同步数据，而undo log不同，它主要记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据，比如我们删除一条数据的时候，就会在undo log日志文件中新增一条insert语句，如果发生回滚就执行逆操作;
- redo log保证了事务的持久性，undo log保证了事务的原子性和一致性