关于Mysql数据库索引你需要知道的内容

一. 数据库索引是什么

数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。 在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

二. 索引的类别

• 普通索引：仅加速查询
• 唯一索引：加速查询 + 列值唯一（可以有null）
• 主键索引：加速查询 + 列值唯一（不可以有null）+ 表中只有一个
• 组合索引：多列值组成一个索引，专门用于组合搜索，其效率大于索引合并
• 全文索引：对文本的内容进行分词，进行搜索
• 索引合并：使用多个单列索引组合搜索
• 覆盖索引：select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖
• 聚簇索引：表数据是和主键一起存储的，主键索引的叶结点存储行数据(包含了主键值)，二级索引的叶结点存储行的主键值。使用的是B+树作为索引的存储结构，非叶子节点都是索引关键字，但非叶子节点中的关键字中不存储对应记录的具体内容或内容地址。叶子节点上的数据是主键与具体记录(数据内容)

三. 创建索引需要遵循的原则

索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：在经常需要搜索的列上，可以加快搜索的速度；在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：

• 第一：对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
• 第二：对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
• 第三：对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
• 第四：当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。

根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。

唯一索引

唯一索引是不允许其中任何两行具有相同索引值的索引。当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。

主键索引

数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。

聚集索引

在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。

四. 索引的优缺点

为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。 优势：创建索引可以大大提高系统的性能。

• 第一：通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
• 第二：可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
• 第三：可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
• 第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
• 第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？因为，增加索引也有许多不利的方面。索引的缺点

• 第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
• 第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
• 第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。

五. 索引失效的情况以及原因分析

1. 查询条件使用不等式会导致索引失效

不等式 <> ，!=， >, in, or 等会导致索引实现

2.查询条件类型不一致会导致索引失效

说明：一个数据库里面一个状态字段 status 是数字字符类型的，咱们查询的时候直接用数字类型，会导致索引失效，最终会对全表尽心扫描。

3.查询条件使用函数，计算，自动/手动类型转换会导致索引失效

说明：例如使用 函数计算 x+1 、 x-1 、CHAR_LENGTH(x) 等会导致索引失效

4.模糊查询条件前缀会导致索引失效

说明：如 % aa 这样的查询条件

5.最佳左前缀法则（带头索引不能死，中间索引不能断）

如果索引了多个列，要遵守最佳左前缀法则。指的是查询从索引的最左前列开始 并且 不跳过索引中的列。

6.尽量使用覆盖索引（只查询索引的列（索引列和查询列一致）），减少select *

7. 索引失效的原因分分析

7.1 单值索引B+树图

单值索引在B+树的结构里，一个节点只存一个键值对

7.2 联合索引

开局一张图，由数据库的a字段和b字段组成一个联合索引。

从本质上来说，联合索引也是一个B+树，和单值索引不同的是，联合索引的键值对不是1，而是大于1个。

a, b 排序分析

a顺序：1，1，2，2，3，3
b顺序：1，2，1，4，1，2

大家可以发现a字段是有序排列，b字段是无序排列（因为B+树只能选一个字段来构建有序的树）一不小心又会发现，在a相等的情况下，b字段是有序的。 大家想想平时编程中我们要对两个字段排序，是不是先按照第一个字段排序，如果第一个字段出现相等的情况，就用第二个字段排序。这个排序方式同样被用到了B+树里。

分析最佳左前缀原理 先举一个遵循最佳左前缀法则的例子

select * from testTable where a=1 and b=2

分析如下：

首先a字段在B+树上是有序的，所以我们可以通过二分查找法来定位到a=1的位置。其次在a确定的情况下，b是相对有序的，因为有序，所以同样可以通过二分查找法找到b=2的位置。 再来看看不遵循最佳左前缀的例子

select * from testTable where b=2

分析如下：

我们来回想一下b有顺序的前提：在a确定的情况下。现在你的a都飞了，那b肯定是不能确定顺序的，在一个无序的B+树上是无法用二分查找来定位到b字段的。所以这个时候，是用不上索引的。

范围查询右边失效原理

select * from testTable where a>1 and b=2

分析如下：

首先a字段在B+树上是有序的，所以可以用二分查找法定位到1，然后将所有大于1的数据取出来，a可以用到索引。b有序的前提是a是确定的值，那么现在a的值是取大于1的，可能有10个大于1的a，也可能有一百个a。大于1的a那部分的B+树里，b字段是无序的（开局一张图），所以b不能在无序的B+树里用二分查找来查询，b用不到索引。

like索引失效原理

where name like "a%"
where name like "%a%"
where name like "%a"

我们先来了解一下%的用途

• %放在右边，代表查询以"a"开头的数据，如：abc
• 两个%%，代表查询数据中包含"a"的数据，如：cab、cba、abc
• %放在左边，代表查询以"a"为结尾的数据，如cba

为什么%放在右边有时候能用到索引

• %放右边叫做：前缀
• %放在左边叫做：后缀

没错，这里依然是最佳左前缀法则这个概念

大家可以看到，上面的B+树是由字符串组成的。

字符串的排序方式：先按照第一个字母排序，如果第一个字母相同，就按照第二个字母排序。。。以此类推

开始分析

一、%号放右边（前缀）

由于B+树的索引顺序，是按照首字母的大小进行排序，前缀匹配又是匹配首字母。所以可以在B+树上进行有序的查找，查找首字母符合要求的数据。所以有些时候可以用到索引。

二、%号放左边

是匹配字符串尾部的数据，我们上面说了排序规则，尾部的字母是没有顺序的，所以不能按照索引顺序查询，就用不到索引。

三、两个%%号

这个是查询任意位置的字母满足条件即可，只有首字母是进行索引排序的，其他位置的字母都是相对无序的，所以查找任意位置的字母是用不上索引的。

六. MyISAM和InnoDB

1.数据库引擎InnoDB与MyISAM的区别

InnoDB

• 是 MySQL 默认的事务型存储引擎，只有在需要它不支持的特性时，才考虑使用其它存储引擎。
• 实现了四个标准的隔离级别，默认级别是可重复读(REPEATABLE READ)。在可重复读隔离级别下，通过多版本并发控制(MVCC)+ 间隙锁(Next-Key Locking)防止幻影读。
• 主索引是聚簇索引，在索引中保存了数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。
• 内部做了很多优化，包括从磁盘读取数据时采用的可预测性读、能够加快读操作并且自动创建的自适应哈希索引、能够加速插入操作的插入缓冲区等。
• 支持真正的在线热备份。其它存储引擎不支持在线热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。

MyISAM

• 设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用它。
• 提供了大量的特性，包括压缩表、空间数据索引等。
• 不支持事务。
• 不支持行级锁，只能对整张表加锁，读取时会对需要读到的所有表加共享锁，写入时则对表加排它锁。但在表有读取操作的同时，也可以往表中插入新的记录，这被称为并发插入(CONCURRENT INSERT)。

InnoDB和MyISAM小结

• 事务: InnoDB 是事务型的，可以使用 Commit 和 Rollback 语句。
• 并发: MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
• 外键: InnoDB 支持外键。
• 备份: InnoDB 支持在线热备份。
• 崩溃恢复: MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
• 其它特性: MyISAM 支持压缩表和空间数据索引。

InnoDB和MyISAM适用场景

• 1.事务：MyISAM不支持，InnoDB支持
• 2.锁级别： MyISAM 表级锁，InnoDB 行级锁及外键约束
• 3.MyISAM存储表的总行数；InnoDB不存储总行数；
• 4.MyISAM采用非聚集索引，B+树叶子存储指向数据文件的指针。InnoDB主键索引采用聚集索引，B+树叶子存储数据

适用场景： MyISAM适合： 插入不频繁，查询非常频繁，如果执行大量的SELECT，MyISAM是更好的选择， 没有事务。 InnoDB适合： 可靠性要求比较高，或者要求事务； 表更新和查询都相当的频繁， 大量的INSERT或UPDATE

2. MyISAM和InnoDB实现B树索引方式的区别是什么

• MyISAM，B+Tree叶节点的data域存放的是数据记录的地址，在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的key存在，则取出其data域的值，然后以data域的值为地址读取相应的数据记录，这被称为“非聚簇索引”
• InnoDB，其数据文件本身就是索引文件，相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的节点data域保存了完整的数据记录，这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引，这被称为“聚簇索引”或者聚集索引，而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址，这也是和MyISAM不同的地方。 在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。因此，在设计表的时候，不建议使用过长的字段为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。

文章来自问我学院（问我社区）；原文链接：http://www.wenwoha.com/8/course_article?act_id=62