互联网大厂面试考点————MySQL

博客地址： Coding Lemon’s blog
所有文章会第一时间在博客更新！

通过打星与加粗的方式对下面面试题的重要性进行评级！难度是针对互联网大厂的。

• ⭐ ：面试中不常问到，如果面试官问到尽量能答出来，答不出来也没关系。
• ⭐⭐ ：面试中不常问到，但是如果面试官问到的话，答不出来对你的印象会减分。
• ⭐⭐⭐：面试中会问到，答不出来面试有点悬。面试官会惊讶为什么你这也不会。
• ⭐⭐⭐⭐：面试高频考点。
• ⭐⭐⭐⭐⭐：面试超高频考点。四星考点和五星考点是参加十场面试，至少能有五场面试问到这些的。大家在准备面试过程中尽量把这些知识点的回答条理梳理清楚，面试官一问就开背。

1. B树和B+树的区别，为什么MySQL使用B+树（⭐⭐⭐⭐⭐）

B树的特点：
1.节点排序
2.一个节点了可以存多个元素，多个元素也排序了

B+树的特点：

1，拥有B树的特点
2.叶子节点之间有指针
3．非叶子节点上的元素在叶子节点上都冗余了，也就是叶子节点中存储了所有的元素，并且排好顺序

使用B+树而不使用B树的原因：

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

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

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

PS：我在知乎上看到有人是这样说的,我感觉说的也挺有道理的：

他们认为数据库索引采用B+树的主要原因是：B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。

MySQL中MyISAM和InnoDB都是采用的B+树结构。不同的是前者是非聚集索引，后者主键是聚集索引，所谓聚集索引是物理地址连续存放的索引，在取区间的时候，查找速度非常快，但同样的，插入的速度也会受到影响而降低。聚集索引的物理位置使用链表来进行存储。

总结：B+树更加“矮胖”，检索速度更快，而且相同空间可以存储更多数据。另外更重要的一点是所有数据存储在叶子节点，更容易进行全盘扫描，效率更高。

2. Mysql锁有哪些，如何理解（⭐⭐⭐⭐）

按锁粒度分类:

1．行锁:锁某行数据，锁粒度最小，并发度高
2．表锁:锁整张表，锁粒度最大，并发度低
3．间隙锁:锁的是一个区间

还可以分为:

1．共享锁:也就是读锁，一个事务给某行数据加了读锁，其他事务也可以读，但是不能写
2.排它锁:也就是写锁，一个事务给某行数据加了写锁，其他事务不能读，也不能写

还可以分为：

1．乐观锁:并不会真正的去锁某行记录，而是通过一个版本号来实现的
2．悲观锁:上面所的行锁、表锁等都是悲观锁

在事务的隔离级别实现中，就需要利用锁来解决幻读。

基于锁的属性分类:共享锁、排他锁。

基于锁的粒度分类:行级锁(INNODB)、表级锁(INNODB、MYISAM)、页级锁(BDB引擎)、记录锁、间隙锁、临键锁。

基于锁的状态分类:意向共享锁、意向排它锁。

• 共享锁(Share Lock)
  共享锁又称读锁，简称S锁;当一个事务为数据加上读锁之后，其他事务只能对该数据加读锁，而不能对数据加写锁，直到所有的读锁释放之后其他事务才能对其进行加持写锁。共享锁的特性主要是为了支持并发的读取数据，读取数据的时候不支持修改，避免出现重复读的问题。

• 排他锁(exclusive Lock)
  排他锁又称写锁，简称x锁;当一个事务为数据加上写锁时，其他请求将不能再为数据加任何锁，直到该锁释放之后，其他事务才能对数据进行加锁。排他锁的目的是在数据修改时候，不允许其他人同时修改，也不允许其他人读取。避免了出现脏数据和脏读的问题。

• 表锁
  表锁是指上锁的时候锁住的是整个表，当下一个事务访问该表的时候，必须等前一个事务释放了锁才能进行对表进行访间;
  特点:粒度大，加锁简单，容易冲突;

• 行锁
  行锁是指上锁的时候锁住的是表的某一行或多行记录，其他事务访问同一张表时，只有被锁住的记录不能访问，其他的记录可正常访问;
  特点:粒度小，加锁比表锁麻烦，不容易冲突，相比表锁支持的并发要高;

• 记录锁(Record Lock)
  记录锁也属于行锁中的一种，只不过记录锁的范围只是表中的某一条记录，记录锁是说事务在加锁后锁住的只是表的某一条记录。
  精准条件命中，并且命中的条件字段是唯一索引
  加了记录锁之后数据可以避免数据在查询的时候被修改的重复读问题，也避免了在修改的事务未提交前被其他事务读取的脏读问题。

• 页锁
  页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
  特点:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般

• 间隙锁(Gap Lock)
  属于行锁中的一种，间隙锁是在事务加锁后其锁住的是表记录的某一个区间,当表的相邻ID之间出现空隙则会形成一个区间，遵循左开右闭原则。
  范围查询并且查询未命中记录，查询条件必须命中索引、间隙锁只会出现在REPEATABLE_READ（重复读)的事务级别中。
  触发条件:防止幻读问题，事务并发的时候，如果没有间隙锁，就会发生如下图的问题，在同一个事务里，A事务的两次查询出的结果会不一样。
  比如表里面的数据ID为1,4,5,7,10 ,那么会形成以下几个间隙区间，-n-1区间，1-4区间，7-10区间，10-n区间(-n代表负无穷大，n代表正无穷大)

• 临建锁(Next-Key Lock)
  也属于行锁的一种，并且它是INNODB的行锁默认算法，总结来说它就是记录锁和间隙锁的组合，临键锁会把查询出来的记录锁住，同时也会把该范围查询内的所有问隙空间也会锁住，再之它会把相邻的下一个区间也会锁住
  触发条件:范围查询并命中，查询命中了索引。
  结合记录锁和间隙锁的特性，临键锁避免了在范围查询时出现脏读、重复读、幻读问题。加了临键锁之后，在范围区间内数据不允许被修改和插入。

3. 如何找出慢查询语句？执行计划explain（⭐⭐⭐⭐）

使用explain。explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。

例如有这样一条sql语句：

EXPLAIN SELECT s.uid,s.username,s.name,f.email,f.mobile,f.phone,f.postalcode,f.address
FROM uchome_space AS s,uchome_spacefield AS f
WHERE 1
AND s.groupid=0
AND s.uid=f.uid

explain语句结果中各个字段的含义：

列名	描述
id	查询语句中每出现一个SELECT关键字，MySQL就会为它分配一个唯一的id值，某些子查询会被优化为join查询，那么出现的id会一样
select_type	SELECT关键字对应的那个查询的类型
table	表名
partitions	匹配的分区信息
type	针对单表的查询方式(全表扫描、索引)
possible_keys	可能用到的索引
key	实际上使用的索引
key_len	实际使用到的索引长度
ref	当使用索引列等值查询时，与索引列进行等值匹配的对象信息
rows	预估的需要读取的记录条数
filtered	某个表经过搜索条件过滤后剩余记录条数的百分比
Extra	一些额外的信息，比如排序等

3.1 id

id是一个有顺序的编号，是查询的顺序号，有几个select就显示几行。id的顺序是按select 出现的顺序增长的。id列的值越大执行优先级越高越先执行，id列的值相同则从上往下执行，id列的值为NULL最后执行。

3.2 selectType

selectType表示查询中每个select子句的类型。

• SIMPLE:表示此查询不包含UNION查询或子查询
• PRIMARY:表示此查询是最外层的查询(包含子查询).
• SUBQUERY:子查询中的第一个SELECT
• UNION:表示此查询是UNION的第二或随后的查询
• DEPENDENT UNION: UNION中的第二个或后面的查询语句,取决于外面的查询
• UNION RESULT,UNION的结果
• DEPENDENTSUBQUERY:子查询中的第一个SELECT,取决于外面的查询.即子查询依赖于外层查询的结果.
• DERIVED:衍生，表示导出表的SELECT (FROM子句的子查询)

3.3 table

表示该语句查询的表

3.4 type

优化sql的重要字段，也是我们判断sql性能和优化程度重要指标。他的取值类型范围:

• const:通过索引一次命中，匹配一行数据
• system:表中只有一行记录，相当于系统表
• eq_ref:唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配
• ref:非唯一性索引扫描,返回匹配某个值的所有
• range:只检索给定范围的行，使用一个索引来选择行，一般用于between、<、>;
• index:只遍历索引树;
• ALL:表示全表扫描，这个类型的查询是性能最差的查询之一。那么基本就是随着表的数量增多，执行效率越慢。

执行效率:
ALL < index <range<ref<eq_ref <const < system。最好是避免ALL和index

3.5 possible_keys

它表示Mysql在执行该sql语句的时候，可能用到的索引信息，仅仅是可能，实际不一定会用到。

3.6 key

此字段是mysql在当前查询时所真正使用到的索引。他是possible_keys的子集

3.7 key_len

表示查询优化器使用了索引的字节数，这个字段可以评估组合索引是否完全被使用，这也是我们优化sql时，评估索引的重要指标

3.8 ref

当使用索引列等值查询时，与索引列进行等值匹配的对象信息

3.9 rows

mysql查询优化器根据统计信息，估算该sql返回结果集需要扫描读取的行数，这个值相关重要，索引优化之后，扫描读取的行数越多，说明索引设置不对，或者字段传入的类型之类的问题，说明要优化空间越大

3.10 filtered

返回结果的行占需要读到的行(rows列的值)的百分比，就是百分比越高，说明需要查询到数据越准确，百分比越小，说明查询到的数据量大，而结果集很少

3.11 extra

• using filesort:表示mysql对结果集进行外部排序，不能通过索引顺序达到排序效果。一般有using filesort都建议优化去掉，因为这样的查询cpu资源消耗大，延时大。
• using index:覆盖索引扫描，表示查询在索引树中就可查找所需数据，不用扫描表数据文件，往往说明性能不错。
• using temporary:查询有使用临时表,一般出现于排序，分组和多表join 的情况，查询效率不高，建议优化。
• using where : sql使用了where过滤,效率较高。

4. Mysql慢查询该如何优化?（⭐⭐⭐⭐）

1．检查是否走了索引，如果没有则优化SQL利用索引
2．检查所利用的索引，是否是最优索引
3．检查所查字段是否都是必须的，是否查询了过多字段，查出了多余数据
4．检查表中数据是否过多，是否应该进行分库分表了
5．检查数据库实例所在机器的性能配置，是否太低，是否可以适当增加资源

其实这里如果展开说可以说很久，但是需要自己实际操作过并且足够清楚。

5. 什么是最左前缀原则？（⭐⭐⭐）

当一个SQL想要利用索引时，就一定要提供该索引所对应的字段中最左边的字段，也就是排在最前面的字段，比如针对abc三个字段建立了一个联合索引，那么在写一个sql时就一定要提供a字段的条件，这样才能用到联合索引，这是由于在建立abc三个字段的联合索引时，底层的B+树是按照a,b,c三个字段从左往右去比较大小进行排序的，所以如果想要利用B+树进行快速查找也得符合这个规则。最佳左前缀法则：带头大哥不能死、中间兄弟不能断

6. Innodb是如何实现事务的？（⭐⭐⭐⭐⭐）

Innodb通过Buffer Pool，LogBuffer，Redo Log,Undo Log来实现事务，以一个update语句为例:

1.Innodb在收到一个update语句后，会先根据条件找到数据所在的页，并将该页缓存在Buffer Pool中
2．执行update语句，修改Buffer Pool中的数据，也就是内存中的数据
3．针对update语句生成一个RedoLog对象，并存入LogBuffer中
4．针对update语句生成undolog日志，用于事务回滚
5．如果事务提交，那么则把RedoLog对象进行持久化，后续还有其他机制将Buffer Pool中所修改的数据页持久化到磁盘中
6．如果事务回滚，则利用undolog日志进行回滚

7. Redis和Mysql如何保证数据一致（⭐⭐⭐⭐⭐）

1．先更新Mysql，再更新Redis，如果更新Redis失败，可能仍然不一致

2．先删除Redis缓存数据，再更新Mysql，再次查询的时候在将数据添加到缓存中，这种方案能解决1方案的问题，但是在高并发下性能较低，而且仍然会出现数据不一致的问题，比如线程1删除了Redis缓存数据，正在更新Mysql，此时另外一个查询再查询，那么就会把Mysql中老数据又查到Redis中

3.延时双删，步骤是:先删除Redis缓存数据，再更新Mysql，延迟几百毫秒再删除Redis缓存数据，这样就算在更新Mysql时,有其他线程读了Mysql，把老数据读到了Redis中，那么也会被删除掉，从而把数据保持一致

8. mysql聚簇和非聚簇索引的区别（⭐⭐⭐⭐）

都是B+树的数据结构

• 聚簇索引:将数据存储与索引放到了一块，并且是按照一定的顺序组织的，找到索引也就找到了数据，数据的物理存放顺序与索引顺序是一致的，即:只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的

• 非聚簇索引:叶子节点不存储数据，存储的是数据行地址，也就是说根据索引查找到数据行的位置再取磁盘查找数据，这个就有点类似一本树的目录，比如我们要找第三章第一节，那我们先在这个目录里面找，找到对应的页码后再去对应的页码看文章。

总结：聚簇索引是索引直接存储数据；非聚簇索引是索引存储了数据地址。

优势:
1、查询通过聚簇索引可以直接获取数据，相比非聚簇索引需要第二次查询（非覆盖索引的情况下）效率要高
2、聚簇索引对于范围查询的效率很高，因为其数据是按照大小排列的
3、聚簇索引适合用在排序的场合，非聚簇索引不适合

劣势:
1、维护索引很昂贵，特别是插入新行或者主键被更新导至要分页(page sp1it)的时候。建议在大量插入新行后，选在负载较低的时间段，通过OPTIMIZE TABLE优化表，因为必须被移动的行数据可能造成碎片。使用独享表空间可以弱化碎片
2、表如果使用UUId（随机ID)作为主键，使数据存储稀疏，这就会出现聚簇索引有可能有比全表扫面更慢，所以建议使用int的auto_increment作为主键
3、如果主键比较大的话，那辅助索引将会变的更大，因为辅助索引的叶子存储的是主键值;过长的主键值，会导致非叶子节点占用占用更多的物理空间

• InnoDB中一定有主键，主键一定是聚簇索引，不手动设置、则会使用unique索引，没有unique索引，则会使用数据库内部的一个行的隐藏id来当作主键索引。在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引，辅助索引叶子节点存储的不再是行的物理位置，而是主键值

• MyISM使用的是非聚簇索引，没有聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。

如果涉及到大数据量的排序、全表扫描、count之类的操作的话，还是MyISAM占优势些，因为索引所占空间小，这些操作是需要在内存中完成的。

9. 索引的设计原则（⭐⭐）

查询更快、占用空间更小

1.适合索引的列是出现在where子句中的列，或者连接子句中指定的列2.基数较小的表，索引效果较差，没有必要在此列建立索引
3.使用短索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间，如果搜索词超过索引前缀长度，则使用索引排除不匹配的行，然后检查其余行是否可能匹配。(例如检索身份证号、手机号，将其反转后进行检索)
4.不要过度索引。索引需要额外的磁盘空间，并降低写操作的性能。在修改表内容的时候，索引会进行更新甚至重构，索引列越多，这个时间就会越长。所以只保持需要的索引有利于查询即可。
5.定义有外键的数据列一定要建立索引。
6.更新频繁字段不适合创建索引
7.若是不能有效区分数据的列不适合做索引列(如性别，男女未知，最多也就三种，区分度实在太低)
8.尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
9.对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。10.对于定义为text、image和bit的数据类型的列不要建立索引。

10. 事务的基本特性和隔离级别？（⭐⭐⭐⭐）

事务基本特性ACID分别是:

• 原子性指的是一个事务中的操作要么全部成功，要么全部失败。
• 一致性指的是数据库总是从一个一致性的状态转换到另外一个一致性的状态。比如A转账给B100块钱，假设A只有90块，支付之前我们数据库里的数据都是符合约束的;但是如果事务执行成功了,我们的数据库数据就破坏约束了,因此事务不能成功,这里我们说事务提供了一致性的保证
• 隔离性指的是一个事务的修改在最终提交前，对其他事务是不可见的。
• 持久性指的是一旦事务提交，所做的修改就会永久保存到数据库中。

隔离性有4个隔离级别，分别是:

• read uncommit读未提交，可能会读到其他事务未提交的数据，也叫做脏读。
  用户本来应该读取到id=1的用户age应该是10，结果读取到了其他事务还没有提交的事务，结果读取结果age=20，这就是脏读。
• read commit读已提交，两次读取结果不一致，叫做不可重复读。不可重复读解决了脏读的问题，他只会读取已经提交的事务。
  用户开启事务读取id=1用户，查询到age=10，再次读取发现结果=20，在同一个事务里同一个查询读取到不同的结果叫做不可重复读。
• repeatable read可重复复读，这是mysql的默认级别，就是每次读取结果都一样，但是有可能产生幻读。
• serializable 串行，一般是不会使用的，他会给每一行读取的数据加锁，会导致大量超时和锁竞争的问题。

脏读(Drity Read):某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。

幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另-个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

11. 关心过业务系统里面的sql耗时吗?统计过慢查询吗?对慢查询都怎么优化过?（⭐⭐⭐⭐）

在业务系统中，除了使用主键进行的查询，其他的都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们。

慢查询的优化首先要搞明白慢的原因是什么?是查询条件没有命中索引?是load了不需要的数据列?还是数据量太大?

所以优化也是针对这三个方向来的:

• 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。
• 分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。
• 如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。

12. MySQL中ACID靠什么保证的?（⭐⭐⭐⭐）

• A原子性由undo log日志保证，它记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的sqlC一致性由其他三大特性保证、程序代码要保证业务上的一致性

• I隔离性由MVCC来保证

• D持久性由内存+redo log来保证，mysql修改数据同时在内存和redo log记录这次操作，宕机的时候可以从redolog恢复

InnoDB redo log写盘，InnoDB事务进入 prepare状态。
如果前面prepare 成功，binlog 写盘，再继续将事务日志持久化到 binlog，如果持久化成功，那么、InnoDB事务则进入commit状态(在 redo log里面写一个commit记录)

redolog的刷盘会在系统空闲时进行

13. mysql主从同步原理？（⭐⭐⭐）

mysql主从同步的过程:

Mysql的主从复制中主要有三个线程: master (binlog dump thread). slave(I/o thread . sQLthread） , Master—条线程和Slave中的两条线程。

• 主节点binlog，主从复制的基础是主库记录数据库的所有变更记录到binlog。binlog是数据库服务器启动的那一刻起，保存所有修改数据库结构或内容的一个文件。
• 主节点 log dump线程，当binlog有变动时，log dump线程读取其内容并发送给从节点。·从节点I/o线程接收binlog内容，并将其写入到relay log文件中。
• 从节点的SQL线程读取relay log文件内容对数据更新进行重放，最终保证主从数据库的一致性。

注:主从节点使用binglog文件+ position偏移量来定位主从同步的位置，从节点会保存其已接收到的偏移量，如果从节点发生宕机重启，则会自动从position 的位置发起同步。

由于mysql默认的复制方式是异步的，主库把日志发送给从库后不关心从库是否已经处理，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。

全同步复制
主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。

半同步复制
和全同步不同的是，半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。

14. 简述MyISAM和InnoDB的区别（⭐⭐⭐⭐）

MyISAM：
不支持事务，但是每次查询都是原子的;
支持表级锁，即每次操作是对整个表加锁;
存储表的总行数;

一个MYISAM表有三个文件:索引文件、表结构文件、数据文件;
采用非聚集索引，索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致，但是辅索引不用保证唯一性。

InnoDb:
支持ACID的事务，支持事务的四种隔离级别;
支持行级锁及外键约束:
因此可以支持写并发;
不存储总行数;

一个InnoDb引擎存储在一个文件空间(共享表空间，表大小不受操作系统控制，一个表可能分布在多个文件里)，也有可能为多个(设置为独立表空，表大小受操作系统文件大小限制，一般为2G)，受操作系统文件大小的限制;

主键索引采用聚集索引(索引的数据域存储数据文件本身)，辅索引的数据域存储主键的值;因此从辅索引查找数据，需要先通过辅索引找到主键值，再访问辅索引;最好使用自增主键，防止插入数据时，为维持B+树结构，文件的大调整。

15. 简述mysql中索引类型及对数据库的性能的影响（⭐⭐⭐）

普通索引:允许被索引的数据列包含重复的值。

唯一索引:可以保证数据记录的唯一性。

主键:是一种特殊的唯一索引，在一张表中只能定义一个主键索引，主键用于唯一标识一条记录，使用关键字PRIMARY KEY 来创建。

联合索引:索引可以覆盖多个数据列，如像INDEX(columnA, columnB)索引。

全文索引:通过建立倒排索引,可以极大的提升检索效率,解决判断字段是否包含的问题，是目前搜索引擎使用的一种关键技术。可以通过ALTER TABLE table_name ADD FULLTEXT (column;创建全文索引

索引可以极大的提高数据的查询速度。
通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
但是会降低插入、删除、更新表的速度，因为在执行这些写操作时，还要操作索引文件
索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大，如果非聚集索引很多，一旦聚集索引改变，那么所有非聚集索引都会跟着变。

16. 什么是MVCC？（⭐⭐⭐⭐⭐）

多版本并发控制:读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事务session会看到自己特定版本的数据，版本链

MVCC只在READ COMMITTED和REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别够和MVCC不兼容,因为READ UNCOMMITTED总是读取最新的数据行,而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

聚簇索引记录中有两个必要的隐藏列:

trx_id:用来存储每次对某条聚簇索引记录进行修改的时候的事务id。
roll_pointer:每次对哪条聚簇索引记录有修改的时候，都会把老版本写入undo日志中。这个roll_pointer就是存了一个指针，它指向这条聚簇索引记录的上一个版本的位置，通过它来获得上一个版本的记录信息。(注意插入操作的undo日志没有这个属性，因为它没有老版本)

已提交读和可重复读的区别就在于它们生成ReadView的策略不同。

开始事务时创建readview,readView维护当前活动的事务id，即未提交的事务id，排序生成一个数组

访问数据，获取数据中的事务id(获取的是事务id最大的记录)，对比readview:

如果在readview的左边(比readview都小)，可以访问(在左边意味着该事务已经提交)

如果在readview的右边(比readview都大）或者就在readview中，不可以访问，获取roll_pointer，取上一版本重新对比(在右边意味着，该事务在readview生成之后出现，在readview中意味着该事务还未提交)

已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView,而可重复读隔离级别则在第一次读的时候生成一个ReadView，之后的读都复用之前的ReadView。

这就是Mysql的MVCC,通过版本链，实现多版本，可并发读·写，写-读。通过ReadView生成策略的不同实现不同的隔离级别。