本文共 9167 字，大约阅读时间需要 30 分钟。

#【 大话Mysql面试】-Mysql索引

为什么需要索引？什么样的信息可以作为索引？索引的数据结构？

索引的数据结构：二叉查找树、平衡二叉树AVL、红黑树、B-Tree、B+ Tree。

7.1 什么是索引？

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含了对数据表里所有记录的引用指针；

索引是一种数据结构。 数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树或变种B+树。

更通俗来说，索引就相当于目录，为了方便查找书中的内容，通过对内容建立索引形成目录。 索引是一个文件，是占据物理空间的。

7.2 索引的优缺点

索引的优点：

• 可以大大加快数的检索速度，这也是创建索引的最主要的原因；
• 通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能；

索引的缺点：

• **时间方面：创建索引和维护索引要耗费时间。**具体来将，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，会降低增删改的执行效率。
• 空间方面：索引需要占据物理空间

7.3 索引使用场景(重点)

上图中，根据id查询记录，因为id字段仅建立了主键索引，因此此SQL执行可选的索引只有主键索引，如果有多个，最终会选一个较优的作为检索的依据。

-- 增加一个没有建立索引的字段alter table innodb1 add sex char(1);-- 按sex检索时可选的索引为nullEXPLAIN SELECT * from innodb1 where sex='男';

可以尝试在一个字段未建立索引时，根据该字段查询的效率，然后对该字段建立索引（alter table 表名 add index(字段名)），同样的SQL执行的效率，你会发现查询效率会有明显的提升（数据量越大越明显）。

order by

当我们使用order by将查询结果按照某个字段排序时，如果该字段没有建立索引，那么执行计划会将查询出的所有数据使用外部排序（将数据从硬盘分批读取到内存使用内部排序，最后合并排序结果），这个操作是很影响性能的，因为需要将查询涉及到的所有数据从磁盘中读到内存（如果单条数据过大或者数据量过多都会降低效率），更无论读到内存之后的排序了。

但是如果我们对该字段建立索引alter table 表名 add index(字段名)，那么由于索引本身是有序的，因此直接按照索引的顺序和映射关系逐条取出数据即可。而且如果分页的，那么只用取出索引表某个范围内的索引对应的数据，而不用像上述那取出所有数据进行排序再返回某个范围内的数据。（从磁盘取数据是最影响性能的）

join

对join语句匹配关系（on）涉及的字段建立索引能够提高效率

索引覆盖

如果要查询的字段都建立过索引，那么引擎会直接在索引表中查询而不会访问原始数据（否则只要有一个字段没有建立索引就会做全表扫描），这叫索引覆盖。因此我们需要尽可能的在select后只写必要的查询字段，以增加索引覆盖的几率。

这里值得注意的是不要想着为每个字段建立索引，因为优先使用索引的优势就在于其体积小。

7.4 索引有哪几种类型？

主键索引: 数据列不允许重复，不允许为NULL，一个表只能有一个主键。

唯一索引: 数据列不允许重复，允许为NULL值，一个表允许多个列创建唯一索引。

• 可以通过 ALTER TABLE table_name ADD UNIQUE (column); 创建唯一索引
• 可以通过 ALTER TABLE table_name ADD UNIQUE (column1,column2); 创建唯一组合索引

普通索引: 基本的索引类型，没有唯一性的限制，允许为NULL值。

• 可以通过ALTER TABLE table_name ADD INDEX index_name (column);创建普通索引
• 可以通过ALTER TABLE table_name ADD INDEX index_name(column1, column2, column3);创建组合索引

全文索引： 是目前搜索引擎使用的一种关键技术。

• 可以通过ALTER TABLE table_name ADD FULLTEXT (column);创建全文索引

7.5 索引的数据结构(B树，Hash)

索引的数据结构和具体存储引擎的实现有关，在MySQL中使用较多的索引有Hash索引，B+树索引等，而我们经常使用的InnoDB存储引擎的默认索引实现为：B+树索引。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。

(1)B树索引

mysql通过存储引擎取数据，基本上90%的人用的就是InnoDB了，按照实现方式分，InnoDB的索引类型目前只有两种：BTREE（B树）索引和HASH索引。B树索引是Mysql数据库中使用最频繁的索引类型，基本所有存储引擎都支持BTree索引。通常我们说的索引不出意外指的就是（B树）索引（实际是用B+树实现的，因为在查看表索引时，mysql一律打印BTREE，所以简称为B树索引）

查询方式：

主键索引区:PI(关联保存的时数据的地址)按主键查询,

普通索引区:si(关联的id的地址,然后再到达上面的地址)。所以按主键查询,速度最快

B+tree性质：

• a. n棵子tree的节点包含n个关键字，不用来保存数据而是保存数据的索引。
• b. 所有的叶子结点中包含了全部关键字的信息，及指向含这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
• c. 所有的非终端结点可以看成是索引部分，结点中仅含其子树中的最大（或最小）关键字。
• d. B+ 树中，数据对象的插入和删除仅在叶节点上进行。
• e. B+树有2个头指针，一个是树的根节点，一个是最小关键码的叶节点。

(2) 哈希索引

简要说下，类似于数据结构中简单实现的HASH表（散列表）一样，当我们在mysql中用哈希索引时，主要就是通过Hash算法（常见的Hash算法有直接定址法、平方取中法、折叠法、除数取余法、随机数法），将数据库字段数据转换成定长的Hash值，与这条数据的行指针一并存入Hash表的对应位置；如果发生Hash碰撞（两个不同关键字的Hash值相同），则在对应Hash键下以链表形式存储。当然这只是简略模拟图。

7.6 索引的基本原理

索引用来快速地寻找那些具有特定值的记录。如果没有索引，一般来说执行查询时遍历整张表。

索引的原理很简单，就是把无序的数据变成有序的查询。

• 把创建了索引的列的内容进行排序；
• 对排序结果生成倒排表；
• 在倒排表内容上拼上数据地址链；
• 在查询的时候，先拿到倒排表内容，再取出数据地址链，从而拿到具体数据。

7.7 索引的算法有哪些？

索引算法有BTree算法和Hash算法。

BTree算法

BTree是最常用的mysql数据库索引算法，也是mysql默认的算法。因为它不仅可以被用在=,>,>=,<,<=和between这些比较操作符上，而且还可以用于like操作符，只要它的查询条件是一个不以通配符开头的常量， 例如：

-- 只要它的查询条件是一个不以通配符开头的常量select * from user where name like 'jack%'; -- 如果一通配符开头，或者没有使用常量，则不会使用索引，例如： select * from user where name like '%jack';

Hash算法

Hash Hash索引只能用于对等比较，例如=,<=>（相当于=）操作符。由于是一次定位数据，不像BTree索引需要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以检索效率远高于BTree索引。

7.8 索引设计的原则？

• 适合索引的列是出现在where子句中的列，或者连接子句中指定的列；
• 基数较小的类，索引效果较差，没有必要在此列建立索引；
• 使用短索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间；
• 不过过度索引。索引需要额外的磁盘空间，并会降低写操作的性能。在修改表内容的时候，索引会进行更新甚至重构，索引列越多，这个时间就会越长。所以只保持需要的索引有利于查询即可。

7.9 创建索引的方式

第一种方式：在执行CREATE TABLE时创建索引

CREATE TABLE user_index2 (	id INT auto_increment PRIMARY KEY,	first_name VARCHAR (16),	last_name VARCHAR (16),	id_card VARCHAR (18),	information text,	KEY name (first_name, last_name),	FULLTEXT KEY (information),	UNIQUE KEY (id_card));

第二种方式：使用ALTER TABLE命令去增加索引

ALTER TABLE table_name ADD INDEX index_name (column_list);

ALTER TABLE用来创建普通索引、UNIQUE索引或PRIMARY KEY索引。

其中table_name是要增加索引的表名，column_list指出对哪些列进行索引，多列时各列之间用逗号分隔。

索引名index_name可自己命名，缺省时，MySQL将根据第一个索引列赋一个名称。另外，ALTER TABLE允许在单个语句中更改多个表，因此可以在同时创建多个索引。

第三种方式：使用CREATE INDEX命令创建

CREATE INDEX index_name ON table_name (column_list);

CREATE INDEX可对表增加普通索引或UNIQUE索引。（但是，不能创建PRIMARY KEY索引）

删除索引

根据索引名删除普通索引、唯一索引、全文索引：alter table 表名 drop KEY 索引名

alter table user_index drop KEY name;alter table user_index drop KEY id_card;alter table user_index drop KEY information;

删除主键索引：alter table 表名 drop primary key（因为主键只有一个）。这里值得注意的是，如果主键自增长，那么不能直接执行此操作（自增长依赖于主键索引）：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UkUNgLRW-1616915189460)(E:/笔记/JAVA/Java复习框架-数据库/Mysql/imgs_mysql/15.png)]

需要取消自增长再行删除：

alter table user_index-- 重新定义字段MODIFY id int,drop PRIMARY KEY

但通常不会删除主键，因为设计主键一定与业务逻辑无关。

创建索引时需要注意什么？

• 非空字段：应该指定列为NOT NULL,除非你想存储NULL。在mysql中，含有控制的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加发复杂。应该用0、一个特殊的值或者一个空串代替空值；
• 取值离散大的字段：（变量各个取值之间的差异程度）的列放到联合索引的前面，可以通过count()函数查看字段的差异值，返回值越大说明字段的谓一致越多，字段的离散程度高；
• 索引字段越小越好： 数据库的数据存储以页为单位存储，一页存储的数据越多，一次IO操作获取的数据越多，效率越高。

7.10 使用索引查询一定能提高查询的性能吗？为什么？

通常，通过索引查询数据比全表扫描要快。但是我们也要注意到它的代价。

• 索引需要空间来存储，也需要定期维护。每当有记录在表中增减或索引列被修改时，索引本身也会被修改。这意味着没调记录的INSET,DELETE,UPDATE将为此多付出4,5次的磁盘I/O操作。此外因为索引需要额外的存储空间和处理，那些不必要的索引反而会使查询反应时间变慢。使用索引查询不一定能提高查询性能，索引范围查询(INDEX RANGE SCAN)适用于两种情况：
  • 基于一个范围的检索，一般查询返回结果集小于表中记录数的30%；
  • 基于非唯一性索引的检索；

7.11 百万级别或以上的数据如何删除？

关于索引：由于索引需要额外的维护成本，因为索引文件是单独存在的文件,所以当我们对数据的增加,修改,删除,都会产生额外的对索引文件的操作,这些操作需要消耗额外的IO,会降低增/改/删的执行效率。所以，在我们删除数据库百万级别数据的时候，查询MySQL官方手册得知删除数据的速度和创建的索引数量是成正比的。

• 要删除百万数据时可以先删除索引(此时耗时大概3分钟)；
• 之后删除其中无用数据(此过程不到2分钟)
• 删除完成后重新创建索引(此时数据较小)，创建索引非常快；
• 相比较之前的直接删除绝对是要快速很多，更别说万一删除中断，一切删除会回滚。

7.12 前缀索引

语法：index(field(10))，使用字段值的前10个字符建立索引，默认是使用字段的全部内容建立索引。

前提：前缀的标识度高。比如密码就适合建立前缀索引，因为密码几乎各不相同。

实操的难度：在于前缀截取的长度。

我们可以利用select count(*)/count(distinct left(password,prefixLen));，通过从调整prefixLen的值（从1自增）查看不同前缀长度的一个平均匹配度，接近1时就可以了（表示一个密码的前prefixLen个字符几乎能确定唯一一条记录）

7.13 什么是最前缀原则？什么是最左匹配原则

在mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配，示例：

对列col1、列col2和列col3建一个联合索引

KEY index_col1_col2_col3 on test(col1,col2,col3);

联合索引 index_col1_col2_col3 实际建立了(col1)、(col1,col2)、(col,col2,col3)三个索引。

SELECT * FROM table WHERE col1="1" AND clo2="2" AND clo4="4"

上面这个查询语句执行时会依照最左前缀匹配原则，检索时会使用索引(col1,col2)进行数据匹配。索引的字段可以是任意顺序的。

例子：索引的最左前缀原理：

通常我们在建立联合索引的时候，也就是对多个字段建立索引，相信建立过索引的同学们会发现，无论是oralce还是mysql都会让我们选择索引的顺序，比如我们想在a,b,c三个字段上建立一个联合索引，我们可以选择自己想要的优先级，a、b、c,或者是b、a、c 或者是c、a、b等顺序。为什么数据库会让我们选择字段的顺序呢？不都是三个字段的联合索引么？这里就引出了数据库索引的最左前缀原理。

比如：索引index1:(a,b,c)有三个字段，我们在使用sql语句来查询的时候，会发现很多情况下不按照我们想象的来走索引。

select * from table where c = ‘1’ 这个sql语句是不会走index1索引的，select * from table where b =‘1’ and c =‘2’ 这个语句也不会走index1索引。

什么语句会走index1索引呢？

答案是：

select * from table where a = ‘1’

select * from table where a = ‘1’ and b = ‘2’

select * from table where a = ‘1’ and b = ‘2’ and c=‘3’

我们可以发现一个共同点，就是所有走索引index1的sql语句的查询条件里面都带有a字段，那么问题来了，index1的索引的最左边的列字段是a，是不是查询条件中包含a就会走索引呢？

7.14 B树和B+树的区别是什么？

• 在B树中，你可以将键和值存放在内部节点和叶子节点；但在B+树中，内部节点都是键，没有值，叶子节点同时存放键和值。
• B+树的叶子节点有一条链相连，而B树的叶子节点各自独立。

使用B树的好处是什么？

B树可以在内部结点同时存储键和值，因此，把频繁访问的数据放在靠近根节点的地方将会大大提高热点数据的查询效率。这种特性使得b树在特定数据重复多次查询的场景中更加有效。

使用B+树的好处是什么？

由于B+树的内部结点只存放键，不存放值。因此一次读取，可以在内存页中获取更多的键，有利于更快地缩小查找范围。B+数的叶节点由一条链相连。因此，当需要进行一次全数据遍历的时候，B+树只需要使用O(logN)的时间找到最小的一个结点，之后通过链进行O(N)的顺序遍历即可。

相比较B树则需要对树的每一层进行遍历，这会需要更多的内存置换次数，因此花费时间更多。

7.15 Hash索引和B+树索引区别？

Hash索引底层实现是Hash表，进行查找时，调用一次hash函数就可以获取到相应的键值对，之后进行回表查询获得实际数据。

B+树底层实现是多路平衡查找树，对于每一次的查询都是从根节点出发，查找到叶子结点方可获取所有键值，之后根据查询判断是否需要回表查询数据。

因为在hash索引中经过hash函数建立索引之后，索引的顺序与原顺序无法保持一致，不能支持范围查询。而B+树的的所有节点皆遵循(左节点小于父节点，右节点大于父节点，多叉树也类似)，天然支持范围。

因此，在大多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度。而不需要使用hash索引。

7.16 数据库为什么使用B+树而不是B树

• B树只适合随机检索，而B+树同时支持随机检索和顺序检索；
• B+树空间利用率更高，可减少I/O次数，磁盘读写代价更低。一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗。B+树的内部结点并没有指向关键字具体信息的指针，只是作为索引使用，其内部结点比B树小，盘块能容纳的结点中关键字数量更多，一次性读入内存中可以查找的关键字也就越多，相对的，IO读写次数也就降低了。而IO读写次数是影响索引检索效率的最大因素；
• B+树的查询效率更加稳定。B树搜索有可能会在非叶子结点结束，越靠近根节点的记录查找时间越短，只要找到关键字即可确定记录的存在，其性能等价于在关键字全集内做一次二分查找。而在B+树中，顺序检索比较明显，随机检索时，任何关键字的查找都必须走一条从根节点到叶节点的路，所有关键字的查找路径长度相同，导致每一个关键字的查询效率相当。
• B-树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。B+树的叶子节点使用指针顺序连接在一起，只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作。
• 增删文件（节点）时，效率更高。因为B+树的叶子节点包含所有关键字，并以有序的链表结构存储，这样可很好提高增删效率。

B树可以在内部节点或叶子节点存储键值信息；B+树只在叶子节点存储键值信息；B+树的查询效率就很稳定，且因为内部结点只存储键的信息，一次性读入内存中可以查找的关键字就越多，IO读写次数降低，效率较高；

B树的叶子节点相互独立，B+树的叶子节点有一条链路相连。

7.17 什么是聚簇索引、非聚簇索引？

• 聚簇索引：将数据存储与索引放到了一起，找到索引也就找到了数据；
• 非聚簇索引：将数据存储与索引分开，索引结构的叶子结点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因

7.18 B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据

在B+树的索引中，叶子节点可能存储了当前的key值，也可能存储了当前的key值以及整行的数据，这就是聚簇索引和非聚簇索引。 在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则挑选一个唯一键建立聚簇索引。如果没有唯一键，则隐式的生成一个键来建立聚簇索引。

当查询使用聚簇索引时，在对应的叶子节点，可以获取到整行数据，因此不用再次进行回表查询。

7.19 非聚簇索引一定会回表查询吗？

不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进行回表查询。

举个简单的例子，假设我们在员工表的年龄上建立了索引，那么当进行select age from employee where age < 20的查询时，在索引的叶子节点上，已经包含了age信息，不会再次进行回表查询。

非聚簇索引的value包含了整行数据，如果命中了，不需要回表查询；

举措索引如果查询的字段 全部命中了索引，也不需要回表查询；

7.20 联合索引是什么？为什么需要注意联合索引中的顺序？

MySQL可以使用多个字段同时建立一个索引**，叫做联合索引**。在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。

具体原因为:

MySQL使用索引时需要索引有序，假设现在建立了"name，age，school"的联合索引，那么索引的排序为: 先按照name排序，如果name相同，则按照age排序，如果age的值也相等，则按照school进行排序。

当进行查询时，此时索引仅仅按照name严格有序，因此必须首先使用name字段进行等值查询，之后对于匹配到的列而言，其按照age字段严格有序，此时可以使用age字段用做索引查找，以此类推。因此在建立联合索引的时候应该注意索引列的顺序，一般情况下，将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。

转载地址：https://codingchaozhang.blog.csdn.net/article/details/115281207 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！