InnoDB和MyISAM中索引存储的区别

• 前言
• 存储引擎介绍
• MyISAM引擎
• InnoDB引擎
• MyISAM索引结构
• InnoDB索引结构
• 聚集索引
• 非聚集索引
• 回表
• 覆盖索引
• MySQL对索引的优化
• Index Condition Pushdown(ICP)
• Multi-Range Read(MRR)
• MRR的工作方式
• INDEX MERGE
• 索引的种类
• B+树索引的类型及使用
• 普通索引
• 唯一索引
• 前缀索引
• 多列联合索引
• 全文索引
• 全文索引不得不说的事
• 哈希索引
• 索引信息分析
• 关于Cardinality
• Cardinality的更新策略
• Cardinality的计算方式
• 索引的使用原则
• 离散度
• 最左匹配原则
• like和_的最左匹配方式
• 联合索引的最左匹配方式
• 其他无法使用索引场景
• 无法使用索引中的特例
• <> 和not in特例
• 最左匹配原则特例
• 总结

前言

上一篇，我们介绍了MySQL为什么最终选择了B+树来作为索引存储的数据结构，想要详细了解，请点击这里。本文将为大家介绍一下B+树在MySQL中是如何落地的，本文主要会对比常用的两种存储引擎InnoDB和MyISAM来进行比较分析。

存储引擎介绍

MySQL的存储引擎是插件式管理的，我们可以自由选择，MySQL中常用的存储引擎有很多种，但是最常用的就是InnoDB和MyISAM，其他存储引擎不在本文内容之列，就不做过多介绍，主要简单介绍一下InnoDB和MyISAM存储引擎。

MyISAM引擎

MyISAM存储引擎不支持行级锁，只有表级锁；不支持事务，也不支持外键，主要面向OLAP应用，是MySQL数据库5.5.8之前版本默认的存储引擎，MyISAM适用于不需要关心事务，读多写少的场景。每张MyISAM表在磁盘上会创建三个文件：.frm，.MYD和.MYI，其中.frm文件为表结构，每个存储引擎都会有这个文件，是用来存储表结构的，.MYD文件用来存储数据，.MYI用来存储索引，也就是说MyISAM的数据和索引是分开存储的，这一点和InnoDB不一样。
在MySQL5.0之前，MyISAM默认支持的表只有4GB，如果要修改默认表大小的话，需要修改参数MAX_ROWS和AVG_ROW_LENGTH的大小，不过这一点在MySQL5.0之后得到了改善，默认大小为256TB，这个大小在绝大部分应用应该都是可以满足要求的。

InnoDB引擎

InnoDB存储引擎支持事务，主要是为了面向在线事务处理(OLTP)的应用而生，支持行锁和外键，其通过使用多版本并发控制(MVCC)来提升高并发性能，实现了SQL标准的4种隔离级别， 关于InnoDB的MVCC，事务和锁，以及InnoDB是如何避免幻读等问题，在下一篇explain详解之后会为大家介绍，请关注我，和孤狼一起学习进步。从MySQL数据库5.5.8版本开始，为MySQL默认存储引擎。每张 InnoDB表在磁盘上会创建两个文件：.frm 和.ibd，其中.frm文件和MyISAM引擎一样，用来存储表结构的，.ibd文件存储的是索引和数据，InnoDB中索引和数据放在同一个文件中。

MyISAM索引结构

MyISAM的B+树里面，叶子节点存储的是当前索引的值以及当前数据文件对应的磁盘地址。所以如果从索引文件.MYI中找到键值后，会根据其存储的磁盘地址到数据文件.MYD 中获取相应的数据记录，在MyISAM引擎中，主键索引和非主键索引没有差别，都是一样存储，MyISAM索引大致结构如下图所示(本人从小就及其不喜欢画画，所以这个图形实在有点丑，好在能表达出大致意思了)：

InnoDB索引结构

InnoDB除了表结构.frm文件外，就只有一个.ibd 文件，索引和数据存储在一起，所以在InnoDB的B+树中叶子节点直接存储的是整条数据记录，而不是记录磁盘地址。InnoDB引擎和MyISAM引擎还有一个最大的不同就是InnoDB引擎是以主键索引来组织数据的（主键索引和非主键索引的存储结构是不同的），InnoDB存储引擎中这种组织数据的方式被称之为聚集索引组织表（clustered index organize table），主键索引也被称之为聚集索引。

聚集索引

聚集索引(又称之为聚簇索引),聚集的术语表示的是索引键值和数据紧凑的存储在一起。而数据又不会同时存在两个地方，所以InnoDB每张表都有且只有一个聚集索引，换言之，也就是说每张表都必须有且只有一个主键。说到这里可能很多人就要反问了，我建表的时候没有主键索引也可以建表成功，那么这又是为什么呢？

其实如果我们没有显示的指定主键，InnoDB会选择一个非空的唯一索引列作为主键，如果这个也没有，那么InnoDB就会选择一个选择其自己内置 的6字节长的ROWID自增列作为主键。InnoDB中聚集索引叶子节点直接存储的是整条数据，也就是说索引搜索到叶子节点之后就可以直接返回数据了，无需再去磁盘获取数据。

InnoDB中聚集索引大致结构如下图所示：

非聚集索引

除了主键索引之外的其他索引都是非聚集索引，既然聚集索引的索引键值和数据行存放在一起，而聚集索引又只有一个，那么非聚集索引又是怎么存储数据的呢？接下来要画重点了哈：
非聚集索引的叶子节点存储的是当前索引的键值和主键索引的键值。大致结构如下图所示：

所以非聚集索引查询数据和聚集索引查询数据是不同的，因为非聚集索引的叶子节点只有当前索引的键值和主键的键值，也就是说查询数据的时候获取到非聚集索引的叶子节点只能拿到当前索引值和主键索引值。

回表

什么是回表？回表指的就是非聚集索引从叶子节点拿到数据(主键的键值)之后，还需要再根据主键键值去扫描主键索引的B+树，这种操作就叫做回表，也就是说他需要扫描两颗B+树，这也就是为什么在InnoDB中主键索引的效率相比较其他索引是最高的。

覆盖索引

前面我们说到了回表操作，那么就还有有这么一种场景是不需要回表的：比如说我们一个查询只需要查询当前索引的值和主键的值，而不需要查其他数据，这时候就不需要回表了，直接就可以返回，这种也称之为覆盖索引，所以这也是为什么不要写select * 的原因，因为select * 肯定无法用到覆盖索引(除非整张表都是索引)，而覆盖索引可以少扫描一颗聚集索引的B+树，而且因为辅助索引不会存储整条数据，所以大小也要远小于聚集索引，因此可以减少大量的I/O操作。需要注意的是，MyISAM引擎中如果查找的数据也包含在索引内，不需要去磁盘找数据，也认为是覆盖索引。

MySQL对索引的优化

Index Condition Pushdown(ICP)

Index Condition Pushdown中文含义为：索引条件下推。是在MySQL5.6版本之后引进的优化措施。MySQL在正常情况下，根据索引进行查询的时候，会在查询出数据之后将数据返回Server层然后进行where条件过滤，而如果支持 Index Condition Pushdown(ICP)之后，MySQL会在从索引层取出数据之后，立刻进行where 条件进行过滤，避免了返回其他无用的数据。所以当where条件可以过滤大量数据的场景下，这种优化措施可以极大的提高查询效率。

Multi-Range Read(MRR)

Multi-Range Read和Index Condition Pushdown一样，也是在MySQL5.6版本之后引进的优化措施。MRR优化的目的是为了减少磁盘的随机IO访问，并且将随机访问转化为顺序的数据访问，所以MRR优化措施对IO-bound型的SQL查询语句可能带来极大的性能提升。

MRR的工作方式

1、将查询得到的辅助索引键值存放于缓存之中，注意，这时候缓存中的数据是根据辅助索引的键值排序的。
2、将缓存中的数据根据row ID(主键)进行重排序。
3、然后再根据row ID(主键)的顺序去访问。

注意2,3中的row ID，《MySQL技术内幕 InnoDB存储引擎》一书中写的是RowID，我不太清楚作者当时想表达的是按照主键，还是MySQL隐藏列ROWID进行排序，但我个人认为如果写成主键会更容易理解，因为如果我们自己创表的时候显示的指定了主键，而且排序和ROWID不一致，那么就应该是按照我们的主键进行排序，否则就达不到实现顺序IO访问的结果，下面附上MySQL官网原文：

可以看到，官网用的是两个单词：row ID，也就是行id，个人认为是可以直接理解成主键的意思，而并不单单指的是MySQL隐藏列ROWID。这里如果我理解错了，欢迎给我留言或者私信。

我们想一想，如果我们通过辅助索引查找到了辅助索引的键值和主键的键值，这时候我们需要回表，假如辅助索引和主键索引顺序相差很大，那么回表查主键B+树的时候，就是随机访问磁盘，也就是随机IO操作，而如果使用了MRR，就会按照主键进行重排序，这时候再回表就是顺序IO，所以说MRR之所以能优化是因为顺序IO访问的效率是远远大于随机IO的。

INDEX MERGE

索引合并优化，MySQL在5.0及之后的版本引入了这种优化方案。这个意思就是我们在一个表中建立了很多单列索引，然后查询的时候同时用到了多列作为条件，MySQL能够识别并使用单列索引进行扫描，然后将结果合并。
这种算法有三个变种：

• or条件的并集（union 或者 union all）
• and条件的交际
• 综合前面两种情况

注意：过多的单列索引大部分情况下并不能提高性能。《高性能MySQL》一书中的作者认为，索引合并虽然是MySQL的优化方案，但是出现了这种现象，更多是说明索引建的很糟糕。

索引的种类

创建索引语法为：

CREATE [UNIQUE | FULLTEXT | SPATIAL] INDEX index_name
    [index_type]
    ON tbl_name (key_part,...)
    [index_option]
    [algorithm_option | lock_option] ...

InnoDB引擎支持如下常见的三种索引：

B+树索引的类型及使用

B+树索引就是我们常见的主键索引，唯一索引等普通索引

普通索引

如：

CREATE INDEX name_index ON test2 (name);

唯一索引

如：

ALTER TABLE test2 DROP INDEX name_index; -- 先删掉上面创建的索引
CREATE UNIQUE INDEX name_index ON test2 (name);

前缀索引

前缀索引只能用在CHAR, VARCHAR, BINARY,VARBINARY及TEXT等字符类型的列上。如下：

ALTER TABLE test2 DROP INDEX name_index; -- 先删掉上面创建的索引
CREATE INDEX name_index ON test2 (name(10));

name(10)就表示只把name中前10位作为索引的列

多列联合索引

可以把多列作为共同索引，如下：

CREATE INDEX id_name_index ON test2 (id,name);

全文索引

每张表最多允许创建一个全文索引，目前只有InnoDB和MyISAM两种存储引擎支持全文索引。全文索引只能在字符类型的字段创建，比如 char、varchar、text等。如下：

ALTER TABLE test2 DROP INDEX name_index; -- 先删掉上面创建的索引
CREATE FULLTEXT INDEX name_index ON test2 (NAME);

请注意，全文索引的查询语法和其他索引不一样，全文索引使用如下语法进行查询：

MATCH (col1,col2,...) AGAINST (expr [search_modifier])

其中:search_modifier有如下选项：

search_modifier:
  {
       IN NATURAL LANGUAGE MODE
     | IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION
     | IN BOOLEAN MODE
     | WITH QUERY EXPANSION
  }

如下示例：

CREATE TABLE articles (
          id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
          title VARCHAR(200),
          body TEXT,
          FULLTEXT (title,body)
        ) ENGINE=InnoDB;
        
INSERT INTO articles (title,body) VALUES
        ('MySQL Tutorial','DBMS stands for DataBase ...'),
        ('How To Use MySQL Well','After you went through a ...'),
        ('Optimizing MySQL','In this tutorial we will show ...'),
        ('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
        ('MySQL vs. YourSQL','In the following database comparison ...'),
        ('MySQL Security','When configured properly, MySQL ...');
        
SELECT * FROM articles WHERe MATCH (title,body) AGAINST ('database' IN NATURAL LANGUAGE MODE);

注意：NATURAL LANGUAGE MODE 表示的是自然语言模式，也是默认的全文索引的查询模式，所以上面示例中的查询也可以直接这么写：

SELECt * FROM articles WHERe MATCH (title,body) AGAINST ('database');

全文索引不得不说的事

在MySQL 5.7.6之前，MySQL全文索引只支持英文全文索引，不支持中文全文索引(只能把整个中文当成一个词语搜索)，如果需要支持中文则需要使用插件ngram来实现，MySQL从5.7.6开始才内置了ngram全文解析器，用来支持中文、日文、韩文分词。

全文索引还有很多细节需要注意的地方，本文篇幅有限，就不进一步阐述了！

哈希索引

InnoDB中的哈希索引是一种自适应哈希索引，也就是说我们不能直接创建哈希索引，目前MySQL引擎中只有Memory引擎支持创建哈希索引

索引信息分析

我们知道，有些查询语句是用不到索引的，那么一句查询语句到底在什么情况下用到索引，什么情况下用不到索引呢？MySQL是如何选择的呢？
新建一张表test：

CREATE TABLE `test` (
  `id` int(5) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) DEFAULT NULL,
  `company` varchar(20) DEFAULT NULL,
  `age` tinyint(2) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `name_index` (`name`),
  KEY `name_age_index` (`name`,`age`)
) ENGINE=InnoDB AUTO_INCREMENT=120 DEFAULT CHARSET=utf8

初始化一些数据，然后先让我们执行一条语句：

SHOW INDEX FROM test

返回结果如下：

注意：第三行和第四行是一个多列索引，这里的查询时按照列显示的
查询结果的字段含义如下：

• Table：表名
• Non_unique：是否非唯一索引，0-否(主键是唯一索引，所以是0) 1-是
• Key_name：索引名称
• Seq_in_index：索引所在位置(组合索引的时候可以看出区别，单列索引都是1)
• Column_name：索引列的名称
• Collation：列是以什么方式存储的，值为A或者Null，对于B+树索引，总是为A，代表排序；而全文索引或者哈希索引则为Null
• Cardinality：索引中唯一值的估计值。这个数字越接近总数，则表示索引的选择性越高，如果这个数很小，那么可以考虑删除这个索引，因为重复值太多，选择性就不高，用到索引的概率也相对较低。
• Sub_part：是否是列的部分被索引。如果索引全部则为Null，如果是对字段的某一长度索引，则显示具体长度。
• Packed：索引值如何被压缩，没有压缩则为Null。
• Null：索引列是否允许Null值
• Index_type：索引的类型
• Comment：关于索引的信息没有在它自己的列中描述，例如，如果索引已禁用，则禁用索引
• Index_comment：创建索引时的comment属性值

关于Cardinality

Cardinality是通过采样来实现计算的，也就是说并不是一个精确值，而是一个统计值，而且这个值并不会实时更新(亲测如果你的表足够小，是会实时更新的)，如果表够大，每次更新都会带来消耗，如果想要手动更新的话，可以使用以下步骤：

• 对InnoDB引擎，可以执行ANALYZE TABLE 表名来强制更新()，
• 对MyISAM引擎，则可以执行命令：myisamchk 表名，注意,这个命令是要到服务器中数据库存储的文件目录里面（通过：SHOW VARIABLES LIKE 'datadir’可以查询到数据存储路径）去执行的，而不是在sql语句里面执行，这一点网上有些博客并没有说清楚。官网介绍还有一种执行方式是myisamchk 表名.MYI也可以执行，亲测后发现是无法执行的，会报错提示无法打开表，据其他博主介绍这个是MySQL5.6之后出现的Bug，本人用的是MySQL5.7.26，有兴趣的可以自己用低版本MySQL尝试一下

Cardinality的更新策略

InnoDB存储引擎内部对更新Cardinality信息的策略有两种：

• 上一次统计Cardinality之后，表中1/16之一的数据发生过变化
• stat_modifier_counter>2,000,000,000：这种情况主要针对的是假如对某一行数据频繁的更改，表中的数据总数是不会发生变化的，第一种策略肯定就不生效了，所以在InnoDB引擎内部有一个计数器stat_modifier_counter，用来统计表发生变化的次数(注意这不是某一行变化的次数，而是整体的变化次数)

Cardinality的计算方式

InnoDB默认对8个叶子节点进行抽样统计，所以如果一张表足够小的话，每次统计的值是一样的，采样统计过程如下：
1、获得叶子节点的总数A
2、随机获取叶子节点8个，并相加，获得总数total
3、(total / 8) * A 得到采样的数据

索引的使用原则

离散度

离散度=count(distinct(column_name)) /count(*)，而count(distinct(column_name))实际上就是上文中介绍的Cardinality值。某一列的离散度越高，也就是说越接近1，则被MySQL优化器选择作为索引的概率就越大。

最左匹配原则

MySQL索引遵循最左匹配原则，这又可以分为两种情况

like和_的最左匹配方式

比如我们在表user中的列name中创建了索引，然后执行查询语句：

select * from user where name like '%张三';
select * from user where name like '_张三';

这两种因为不是从开头开始匹配的，等于跳过了索引的开头部分，根据索引的最左匹配原则，这种情况就不会使用索引

联合索引的最左匹配方式

比如我们在表user中的列name和age中创建了联合索引index(name,age)，然后执行查询语句：

select * from user where name='张三';
select * from user where age=12;
select * from user where name='张三' and age=12;

上面的索引中1和3是可以用到索引的，联合索引可以只使用一列，和第二句，因为跳过了name直接搜索age，违反了最左匹配原则，所以一般不支持索引。

其他无法使用索引场景

• 在索引列上使用函数（replace\SUBSTR\CONCAT\sum count avg等），使用表达式或者计算(+、-、*、/)
• 字符串不加引号，会出现隐式转换，相当于使用函数to_char()
• 使用!，<>，not like，not in等反向查询

这些规则其实也仅仅只是在一般情况下，然后到底用不用索引，最终还是要优化器决定，MySQL优化器是基于基于开销来决定是否使用索引而不是基于规则来决定是否使用索引。
下面让我们来看一下无法使用索引中的特例

无法使用索引中的特例

<> 和not in特例

CREATE TABLE `course` (
 `cid` int(3) NOT NULL,
 `cname` varchar(20) DEFAULT NULL,
 `tid` int(3) DEFAULT NULL,
 PRIMARY KEY (`cid`),
 KEY `cname_tid_index` (`cname`,`tid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
insert  into `course`(`cid`,`cname`,`tid`) values (1,'语文',1),(2,'数据',1),(3,'英语',2),(4,'物理',3);

我们对这张表执行查询语句：

EXPLAIN SELECT * FROM course WHERe cid <>1;
EXPLAIN SELECt * FROM course WHERe cid NOT IN (1);

最左匹配原则特例

还是上面那张表，我们执行下面这个sql去看一下结果：

EXPLAIN SELECt COUNT(*) FROM course GROUP BY tid

可以看到，虽然违反了最左匹配原则，还是用到了索引。

总结

总之，能不能用到索引，我们不要太依赖这些规则，还要自己实际去试一试，正所谓耳听为虚，眼见为实！
下一篇，我将为大家介绍MySQL执行计划EXPLAIN详细说明和实战，请关注我，和孤狼一起学习进步。