1. 请你讲一下InnoDB和MyISAM的区别？

答：1).InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；

2).InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；

3).InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。MyISAM是非聚集索引，也是使用B+Tree作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。也就是说：InnoDB的B+树主键索引的叶子节点就是数据文件，辅助索引的叶子节点是主键的值；而MyISAM的B+树主键索引和辅助索引的叶子节点都是数据文件的地址指针。

4).InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快（注意不能加有任何WHERE条件）；

5).Innodb不支持全文索引，而MyISAM支持全文索引，在涉及全文索引领域的查询效率上MyISAM速度更快高；PS：5.7以后的InnoDB支持全文索引了

6).MyISAM表格可以被压缩后进行查询操作

7).InnoDB支持表、行(默认)级锁，而MyISAM支持表级锁。补充InnoDB的行锁是实现在索引上的，而不是锁在物理行记录上。潜台词是，如果访问没有命中索引，也无法使用行锁，将要退化为表锁。

8).InnoDB表必须有唯一索引（如主键）（用户没有指定的话会自己找/生产一个隐藏列Row_id来充当默认主键），而Myisam可以没有

9).Innodb存储文件有frm、ibd，而Myisam是frm、MYD、MYI。补充Indebt：frm是表定义文件，ibd是数据文件 Myisam：frm是表定义文件，my是数据文件，myi是索引文件

2. InnoDB和MyISAM如何选择?

答：1).是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；

2).如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读也有写，请使用InnoDB。

3).系统崩溃后，MyISAM恢复起来更困难，能否接受；

4).MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。

3. InnoDB为什么推荐使用自增ID作为主键？

答：自增ID可以保证每次插入时B+索引是从右边扩展的，可以避免B+树频繁合并和分裂（对比使用UUID）。如果使用字符串主键和随机主键，会使得数据随机插入，效率比较差。

4. 你来说一下 Mysql 索引有几种类型呢？分别是什么？

答：MySQL 的索引有两种分类方式：逻辑分类和物理分类。

1).按照逻辑分类，索引可分为：

主键索引：一张表只能有一个主键索引，不允许重复、不允许为 NULL；

唯一索引：数据列不允许重复，允许为 NULL 值，一张表可有多个唯一索引，但是一个唯一索引只能包含一列，比如身份证号码、卡号等都可以作为唯一索引；

普通索引：一张表可以创建多个普通索引，一个普通索引可以包含多个字段，允许数据重复，允许 NULL 值插入；

全文索引：让搜索关键词更高效的一种索引。

2).按照物理分类，索引可分为：

聚集索引：一般是表中的主键索引，如果表中没有显示指定主键，则会选择表中的第一个不允许为 NULL 的唯一索引，如果还是没有的话，就采用 Innodb 存储引擎为每行数据内置的6字节ROWID作为聚集索引。每张表只有一个聚集索引，因为聚集索引的键值的逻辑顺序决定了表中相应行的物理顺序。聚集索引在精确查找和范围查找方面有良好的性能表现（相比于普通索引和全表扫描），聚集索引就显得弥足珍贵，聚集索引选择还是要慎重的（一般不会让没有语义的自增 id 充当聚集索引）；

非聚集索引：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同（非主键的那一列），一个表中可以拥有多个非聚集索引。

5. 锁的类型有哪些呢？

答：mysql锁分为共享锁和排他锁，也叫做读锁和写锁。读锁是共享的，可以通过lock in share mode实现，这时候只能读不能写。写锁是排他的，它会阻塞其他的写锁和读锁。从颗粒度来区分，可以分为表锁和行锁两种。表锁会锁定整张表并且阻塞其他用户对该表的所有读写操作，比如alter修改表结构的时候会锁表。行锁又可以分为乐观锁和悲观锁，悲观锁可以通过for update实现，乐观锁则通过版本号实现。

6. 你能说下事务的基本特性和隔离级别吗？

答：1).事务基本特性ACID分别是：

原子性指的是一个事务中的操作要么全部成功，要么全部失败。

一致性指的是数据库总是从一个一致性的状态转换到另外一个一致性的状态。比如A转账给B100块钱，假设中间sql执行过程中系统崩溃A也不会损失100块，因为事务没有提交，修改也就不会保存到数据库。

隔离性指的是一个事务的修改在最终提交前，对其他事务是不可见的。

持久性指的是一旦事务提交，所做的修改就会永久保存到数据库中。

2).而隔离性有4个隔离级别，分别是：

read uncommit读未提交，可能会读到其他事务未提交的数据，也叫做脏读。

read commit读已提交，两次读取结果不一致，叫做不可重复读。

repeatable read可重复复读，这是mysql的默认级别，就是每次读取结果都一样，但是有可能产生幻读。

serializable串行，一般是不会使用的，他会给每一行读取的数据加锁，会导致大量超时和锁竞争的问题。

7. 那ACID靠什么保证的呢？

答：A原子性由undo log日志保证，它记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的sql

C一致性一般由代码层面来保证

I隔离性由MVCC来保证

D持久性有内存+redo log来保证，mysql修改数据同时在内存和redo log记录这次操作，事务提交的时候通过redo log刷盘，宕机的时候可以从redo log恢复。

8. SQL 语句在 MySQL 内部是如何执行的?

答：1).连接器： 身份认证和权限相关(登录 MySQL 的时候)。

2).查询缓存: 执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。

3).分析器: 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。

4).优化器： 按照 MySQL 认为最优的方案去执行。

5).执行器: 执行语句，然后从存储引擎返回数据。

SQL 等执行过程分为两类，一类对于查询等过程如下：权限校验—》查询缓存—》分析器—》优化器—》权限校验—》执行器—》引擎;对于更新等语句执行流程如下：分析器----》权限校验----》执行器—》引擎—redo log prepare—》binlog—》redo log commit

9. 二叉树结构和索引的关系

1).常见的有序二叉树

a.二叉查找树 极端情况会退化为链表、丧失平衡性、无法体现二分查找的优越性【LogN】

b.AVL树 完美平衡的树、但是自平衡效率非常低。

c.红黑树 非完美平衡的树、黑色完美平衡的树、自平衡效率优良

2).二叉树结构不适合数据库索引原因

a.节点稀疏 一个节点只有一个元素（关键字）、很难利用操作系统页读取和存储的特性

b.层级深 100万的二叉树结构，层级至少为20以上 【20次的IO对于数据库而言是灾难性】

c.二叉树结构难以连续地读取

3).二叉树结构的应用场景

非数据密集型的小数据集场景

红黑树HashMap数据结构中

Linux NIO Epoll 网络编程模型 使用了红黑树结构

4).二叉树结构对数据库索引的启发关系

减少层级

增加页内元素的数量

叶子结点使用双向链表结构

10. B树和B+树的区别

1).B树，每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为nul，叶子结点不包含任何关键字信息。

2).B+树，所有的叶子结点中包含了全部关键字的信息，及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接所有的非终端结点可以看成是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。 (而B 树的非终节点也包含需要查找的有效信息)

总结就是：B+树最末端叶子节点包含所有的元素、B树是整棵树包含所有的元素；B+树的最末端叶子节点是链表

11. 为什么说B+树比B树更适合数据库索引？

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

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

3).由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。

12. 什么是主从复制?主从复制的作用？

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。

1).做数据的设备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。

2).架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

3).读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

13. 说说mysql主从同步（复制）怎么做的吧？

1).master数据发生变化，提交完事务后，写入binlog

2).slave连接到master，获取binlog

3).master创建dump线程，推送binglog到slave

4).slave启动一个IO线程读取同步过来的master的binlog，记录到relay log中继日志中

5).slave再开启一个sql线程读取relay log事件并在slave执行，完成同步

6).slave记录自己的binglog

mysql主从复制的过程

14. MySQL索引优化之最左前缀匹配

在复合索引（多个列的索引），查询条件使用索引列从左到右的顺序进行查询。

例子 比如索引三列 (a , b , c )。

select * from t where a = ? -- 使用索引

select * from t where a = ? and b = ? -- 使用索引

select * from t where b = ? and a = ? -- 使用索引

select * from t where a = ? and b = ? and c = ? -- 使用索引

select * from t where b = ? and c = ? -- 不使用索引

select * from t where c = ? -- 不使用索引

最左前缀匹配的原因 ·（关键字）是按照创建索引的列的顺序排布的。

15. MySQL索引优化之覆盖索引

索引列包含了查询列称作覆盖索引。使用覆盖索引可以避免回表。

第一 建议使用覆盖索引来优化查询

第二 不能为了覆盖索引而创建多列索引 【组合索引的列不要超过三列】

不要创建全表列的索引 , 全表列索引属于无效索引，和表几乎等价，浪费写入性能

全表列索引等价于 select distinct * from orders;

16. MySQL索引优化小结

索引列的数据长度越少越好

索引的数量不是越多越好（写入性能差）、越全越好（索引和表几乎等价）

条件查询推荐使用全值匹配

多列索引推荐使用最左前缀匹配

避免在索引列使用函数操作，会导致索引失效

建议指定查询列（优先使用覆盖索引），禁止使用 SELECT *

避免使用不等于匹配、避免使用or连接条件、避免在Where 条件中使用 NOT IN

避免使用NULL、NOT NULL 匹配、推荐所有的表列是非空的

LIKE 模糊匹配建议使用最左前缀匹配 （like 'ABC%'）

推荐查询条件列的类型和索引列的类型一致，避免对索引列进行类型转换

排序的时候，优先使用索引列排序【索引列天然是排序的、排序遵循最左前缀匹配原则order by a】