了解MyISAM与InnoDB的索引差异（转）

Posted 2020-12-01 myseries

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了了解MyISAM与InnoDB的索引差异（转）相关的知识，希望对你有一定的参考价值。

出处原文： 1分钟了解MyISAM与InnoDB的索引差异

数据库的索引分为主键索引（Primary Inkex）与普通索引（Secondary Index）。InnoDB和MyISAM是怎么利用B+树来实现这两类索引，其又有什么差异呢？这是今天要聊的内容。

一，MyISAM的索引

MyISAM的索引与行记录是分开存储的，叫做非聚集索引（UnClustered Index）。

其主键索引与普通索引没有本质差异：

有连续聚集的区域单独存储行记录
主键索引的叶子节点，存储主键，与对应行记录的指针
普通索引的叶子结点，存储索引列，与对应行记录的指针

画外音：MyISAM的表可以没有主键。

主键索引与普通索引是两棵独立的索引B+树，通过索引列查找时，先定位到B+树的叶子节点，再通过指针定位到行记录。

举个例子，MyISAM：

t(id PK, name KEY, sex, flag);

表中有四条记录：

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

其B+树索引构造如上图：

行记录单独存储
id为PK，有一棵id的索引树，叶子指向行记录
name为KEY，有一棵name的索引树，叶子也指向行记录

二、InnoDB的索引

InnoDB的主键索引与行记录是存储在一起的，故叫做聚集索引（Clustered Index）：

没有单独区域存储行记录
主键索引的叶子节点，存储主键，与对应行记录（而不是指针）

画外音：因此，InnoDB的PK查询是非常快的。

因为这个特性，InnoDB的表必须要有聚集索引：

(1)如果表定义了PK，则PK就是聚集索引；

(2)如果表没有定义PK，则第一个非空unique列是聚集索引；

(3)否则，InnoDB会创建一个隐藏的row-id作为聚集索引；

聚集索引，也只能够有一个，因为数据行在物理磁盘上只能有一份聚集存储。

InnoDB的普通索引可以有多个，它与聚集索引是不同的：

普通索引的叶子节点，存储主键（也不是指针）

对于InnoDB表，这里的启示是：

(1)不建议使用较长的列做主键，例如char(64)，因为所有的普通索引都会存储主键，会导致普通索引过于庞大；

(2)建议使用趋势递增的key做主键，由于数据行与索引一体，这样不至于插入记录时，有大量索引分裂，行记录移动；

仍是上面的例子，只是存储引擎换成InnoDB：

t(id PK, name KEY, sex, flag);

表中还是四条记录：

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

其B+树索引构造如上图：

id为PK，行记录和id索引树存储在一起
name为KEY，有一棵name的索引树，叶子存储id

当：

select * from t where name=‘lisi’;

会先通过name辅助索引定位到B+树的叶子节点得到id=5，再通过聚集索引定位到行记录。

画外音：所以，其实扫了2遍索引树。

三，总结

MyISAM和InnoDB都使用B+树来实现索引：

MyISAM的索引与数据分开存储
MyISAM的索引叶子存储指针，主键索引与普通索引无太大区别
InnoDB的聚集索引和数据行统一存储
InnoDB的聚集索引存储数据行本身，普通索引存储主键
InnoDB一定有且只有一个聚集索引
InnoDB建议使用趋势递增整数作为PK，而不宜使用较长的列作为PK

问题：数据库中聚集索引是否存储了真实数据

描述：

　　索引是一种数据结构，b+树的叶子节点中存放的是指向实际行的指针。
　　那么聚集索引呢，InnoDB 的聚簇索引在同一个结构中保存了 B+Tree 索引和数据行，这句话是什么意思？
　　是不是说非聚集索引叶子节点中的指针指向的就是聚集索引中存放的数据行

答：　　

　　InnoDB聚集索引是按照主键（primary key）进行聚集的，每张表只能有一个聚集索引，表数据文件本身就是按B+Tree组织的一个索引结构，叶子节点的data域保存了完整的数据记录；所以说，InnoDB表数据文件本身就是主索引文件，也就是你刚刚说的“同一个结构中保存了 B+Tree 索引和数据行”。聚集索引的方式会使根据主键的范围查找和排序非常快（参考聚集索引的数据结构）。

　　InnoDB辅助索引的实现方式是所有辅助索引都引用主键作为data域，因此辅助索引搜索需要检索两次索引才能获得数据记录，但是这样辅助索引的变更会很方便（不会影响根据主索引组织的数据文件本身），同时因为所有的辅助索引都引用主索引，不建议主索引过大。

B+树在磁盘中的存储

B+树索引并不能直接找到行，只是找到行所在的页，通过把整页读入内存，再在内存中查找。
索引的B+树高度一般为2-4层，查找记录时最多只需要2-4次IO。

为进一步知其所以然，今天来聊聊B+树索引在物理磁盘上是怎么设计存储的。

一、理解为什么要减少磁盘IO次数

众所周知，mysql的数据实际是存储在文件中，而磁盘IO的查找速度是要远小于内存速度的，所以减少磁盘IO的次数能很大程度的提高MySQL性能。

1.1 磁盘IO为什么慢

先温习下知识点：磁盘IO时间 = 寻道 + 磁盘旋转 + 数据传输时间

从磁盘读取数据时，系统会将逻辑地址发给磁盘，磁盘将逻辑地址转换为物理地址（哪个磁道，哪个扇区）。磁头进行机械运动，先找到相应磁道，再找该磁道的对应扇区，扇区是磁盘的最小存储单元（见图1-1）。

1.2 性能对比

机械硬盘的连续读写性能很好，但随机读写性能很差。

顺序访问：内存访问速度是硬盘访问速度的6~7倍（kafka的特点，以后有机会的话再讲一讲）
随机访问：内存访问速度就要比硬盘访问速度快上10万倍以上

随机读写时，磁头需要不停的移动，时间都浪费在了磁头寻址上。而在实际的磁盘存储里，是很少顺序存储的，因为这样的维护成本会很高。

二、索引在磁盘上的存储

知道磁盘IO的性能了吧，接下来看看MySQL是如何根据这种情况来设计索引的物理存储，以下内容以InnoDB引擎为例，MyISAM略有不同，后面再讲。

假设我们有一张这样的表，表中有如图2-0的数据

CREATE TABLE `user` (
  `ID` bigint(11) NOT NULL AUTO_INCREMENT,
  `NAME` varchar(20),
  PRIMARY KEY (`ID`),
  KEY `idx_name` (`NAME`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;