一篇文章带你弄懂mysql的索引！（详解为什么有索引、b+树更适合做索引、索引操作、MyISAM和InnoDB索引实现）

---

一、为什么要引入索引

我们用下面的代码向表中插入800万条数据，用来讨论索引对查询速度的影响：

drop database if exists `bit_index`;
create database if not exists `bit_index` default character set utf8;
use `bit_index`;

-- 构建一个8000000条记录的数据
-- 构建的海量表数据需要有差异性，所以使用存储过程来创建， 拷贝下面代码就可以了，暂时不用理解

-- 产生随机字符串
delimiter $$
create function rand_string(n INT)
returns varchar(255)
begin
declare chars_str varchar(100) default
'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
declare return_str varchar(255) default '';
declare i int default 0;
while i < n do
set return_str =concat(return_str,substring(chars_str,floor(1+rand()*52),1));
set i = i + 1;
end while;
return return_str;
end $$
delimiter ;


-- 产生随机数字
delimiter $$
create function rand_num( )
returns int(5)
begin
declare i int default 0;
set i = floor(10+rand()*500);
return i;
end $$
delimiter ;

-- 创建存储过程，向雇员表添加海量数据
delimiter $$
create procedure insert_emp(in start int(10),in max_num int(10))
begin
declare i int default 0;
set autocommit = 0;
repeat
set i = i + 1;
insert into EMP values ((start+i)
,rand_string(6),'SALESMAN',0001,curdate(),2000,400,rand_num());
until i = max_num
end repeat;
commit;
end $$
delimiter ;

-- 雇员表
CREATE TABLE `EMP` (
  `empno` int(6) unsigned zerofill NOT NULL COMMENT '雇员编号',
  `ename` varchar(10) DEFAULT NULL COMMENT '雇员姓名',
  `job` varchar(9) DEFAULT NULL COMMENT '雇员职位',
  `mgr` int(4) unsigned zerofill DEFAULT NULL COMMENT '雇员领导编号',
  `hiredate` datetime DEFAULT NULL COMMENT '雇佣时间',
  `sal` decimal(7,2) DEFAULT NULL COMMENT '工资月薪',
  `comm` decimal(7,2) DEFAULT NULL COMMENT '奖金',
  `deptno` int(2) unsigned zerofill DEFAULT NULL COMMENT '部门编号'
);


-- 执行存储过程，添加8000000条记录
call insert_emp(100001, 8000000);

下面是无索引的情况下查询一条数据：

我们发现进行一条语句的查询就需要耗费4.52秒，如果同时有1000个人并发查询，那很有可能死机。

我们为表加上索引，再进行查询：

我们发现查询数据的速度快了几百倍！这就体现了索引的作用！！

索引的作用：提高一个海量数据的检索速度。

二、认识磁盘

1.数据存在哪

在我们理解索引之前，我们需要先理解一些关于磁盘的知识。

首先。数据库的数据是存在哪里的呢？毫无疑问，答案是磁盘！

它们以文件的形式存储在磁盘上，在 linux 的var/lib/mysql 目录下：

我们创建的数据库就以目录的方式存放在 mysql 目录中，而目录中存放的是表中的数据：

1. *.frm–表结构的文件。
2. *.ibd–表数据和索引的文件。

2.磁盘结构

下面便是磁盘的结构：

我们只需要知道，磁头（Heads）、柱面(Cylinder)(等价于磁道)、扇区(Sector)对应的编号。即可在磁盘上定位所要访问的扇区。这种磁盘数据定位方式叫做 CHS 。不过实际系统软件使用的并不是 CHS （但是硬件是），而是 LBA ，一种线性地址，可以想象成虚拟地址与物理地址。系统将 LBA 地址最后会转化成为 CHS ，交给磁盘去进行数据读取。不过，我们现在不关心转化细节，知道这个东西，让我们逻辑自洽起来即可。

数据库文件，本质其实就是保存在磁盘的盘片当中。也就是上面的一个个小格子中，就是我们经常所说的扇区。当然，数据库文件很大，也很多，一定需要占据多个扇区。

磁盘扇区的大小通常是512字节。这是因为在传统的硬盘配置中，扇区的大小就是512字节。然而，在高级格式化的硬盘中，物理扇区的大小可能是4096字节，但仍然可以向下兼容512字节。需要注意的是，如果硬盘没有进行4K对齐处理，可能会影响性能。

所以，最基本的，找到一个文件的全部，本质，就是在磁盘找到所有保存文件的扇区。而我们能够定位任何一个扇区，那么便能找到所有扇区，因为查找方式是一样的。

3.MYSQL和磁盘交互的基本单位

现在我们了解了磁盘，那么在系统软件上，就直接按照扇区(512字节，部分4096字节)，进行IO交互吗？不是！

1. 如果操作系统直接使用硬件提供的数据大小进行交互，那么系统的IO代码，就和硬件强相关，换言之，如果硬件发生变化，系统必须跟着变化
2. 从目前来看，单次IO 512字节，还是太小了。IO单位小，意味着读取同样的数据内容，需要进行多次磁盘访问，会带来效率的降低。
3. 文件系统读取基本单位，不是扇区，而是数据块，基本单位是 4KB。

而 MySQL 作为一款应用软件，可以想象成一种特殊的文件系统。它有着更高的IO场景，所以，为了提高基本的IO效率， MySQL 进行IO的基本单位是 16KB（16*1024=16384）。

这个基本数据单元，在MYSQL中叫做page（页），和系统的page不一样！

现在我们可以来达成一些共识：

1. CURD 操作，都需要通过计算，找到对应的插入位置，或者找到对应要修改或者查询的数据。
2. 而只要涉及计算，就需要CPU参与，而为了便于CPU参与，一定要能够先将数据移动到内存当中。
3. 在特定时间内，数据一定是磁盘中有，内存中也有。后续操作完内存数据之后，以特定的刷新策略，刷新到磁盘。而这时，就涉及到磁盘和内存的数据交互，也就是IO了。而此时IO的基本单位就是Page。
4. 为了更好的进行上面的操作， MySQL 服务器在内存中运行的时候，在服务器内部，就申请了被称为 Buffer Pool 的的大内存空间，来进行各种缓存。其实就是很大的内存空间，来和磁盘数据进行IO交互。
5. 为何更高的效率，一定要尽可能的减少系统和磁盘IO的次数

三、理解索引

1.认识索引

我们创建以下表并插入数据：

create table if not exists user (
	id int primary key, --一定要添加主键哦，只有这样才会默认生成主键索引
	age int not null,
	name varchar(16) not null
);

//插入数据
mysql> insert into user (id, age, name) values(3, 18, '杨过');
mysql> insert into user (id, age, name) values(4, 16, '小龙女');
mysql> insert into user (id, age, name) values(2, 26, '黄蓉');
mysql> insert into user (id, age, name) values(5, 36, '郭靖');
mysql> insert into user (id, age, name) values(1, 56, '欧阳锋');

注意，我们插入的时候 id 是无序的：

查询这张表，我们发现竟然是有序的！在解释原因之前，我们先解释一下局部性原理！

1. 局部性原理的思想比较简单，比如目前有三块内存页x、y、z是相连的，CPU此刻在操作x页中的数据，那按照计算机的特性，一般同一个数据都会放入到物理相连的内存地址上存储，也就是当前在操作x页的数据，那么对于y，z这两页内存的数据也很有可能在接下来的时间内被操作，因此对于y，z这两页数据则会提前将其载入到高速缓冲区（L1/L2/L3），这个过程叫做利用局部性原理“预读”数据。
2. 但是一次性到底预读多大的数据放入到高速缓冲区中呢？
   这个是由缓存行大小决定的，比如因特尔的MESI协议中，缓存行的默认大小为64k，也就是说在因特尔的CPU中，一次性会将“当前操作数据”附近的64K数据（16页数据）提前载入进高速缓冲区。
3. OK~，上述内容讲的是操作系统高速缓冲区的知识，在CPU中利用局部性原理，提前将数据从内存先放入L1/L2/L3三级缓冲区中，主要是为了减小CPU寄存器与内存之间的性能差异。
4. OK~，由于CPU寄存器和内存之间的性能差异太大，所以逐个读数据的形式会导致CPU工作期间的大量时间会处于等待数据状态，所以利用局部性原理将数据“预读”到高速区。而对于MySQL而言，亦是同理，存储数据的磁盘和内存之间的性能差异也是巨大的，因为MySQL也会利用局部性原理，提前“预读”数据。
   这是什么意思呢？其实就是指MySQL一次磁盘IO不仅仅只会读取一条表数据，而是会读取多条数据，那到底读多少条数据呢？在InnoDB引擎中，一次默认会读取16KB数据到内存。

所以局部性原理可以解释IO交互为什么要以page方式，也可以解释为什么要排序：

对有序的数据进行查询效率要高于无序的数据，因为page命中率高。

在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

2.索引的结构

我们首先排除链表，因为其O(n)的查找效率，然后我们考虑二叉树：

①如果索引的字段值是按顺序增长的，二叉树会转变为链表结构。
②由于结构转变成了链表结构，因此检索的过程和全表扫描无异。
③由于树结构在磁盘中，各节点的数据并不连续，因此无法利用局部性原理。

既然二叉树不行，我们来看看大名鼎鼎的红黑树：

①虽然对比二叉树来说，树高有所降低，但数据量一大时，依旧会有很大的高度。
②每个节点中只存储一个数据，节点之间还是不连续的，依旧无法利用局部性原理。

对于这两个问题，如果我们能在一个节点储存多个数据是否就能解决？B-Tree就是这样的结构：

首先B-树是一种多路平衡搜索树，简单来说，就是每个节点不止存储一个数据值，每个节点也不止有两个子节点，比起平衡二叉树，它能很大程度减低树的高度，提高树的检索效率。下面是一颗B-Tree：

• 为了描述B-Tree，首先定义一条数据记录为一个二元组[key, data]，key为记录的键值，对于不同数据记录，key是互不相同的；data为数据记录除key外的数据。
  
• B-Tree解决了当数据量过大时，二叉树高度过高的问题，对于局部性原理呢？
  MySQL由于是关系型数据库，因此经常会碰到范围查询的需求，举例：
  select * from user where id between 2 and 5;
  比如上述这条SQL语句，需要查询表中ID在2~ 5的所有数据，那也就代表着需要查四条数据，在这里因为2~ 5在同一个节点中，因此仅触发一次IO就可拿到数据，但实际业务中往往不会有这么小的范围查询，假设此时是查ID=2~1000之间的数据呢？这么多数据定然不会在一个节点中，因此这里又会触发多次磁盘IO！

虽然对比之前的红黑树更矮，检索数据更快，也能够充分利用局部性原理减少IO次数，但对于大范围查询的需求，依旧需要通过多次磁盘IO来检索数据。

我们再来看看B+Tree：

其定义基本和特性与B-树同，最特殊的是：它为所有叶子结点增加一个链指针，所有关键字都在叶子结点出现

• 为了描述B+Tree，首先定义一条数据记录为一个二元组[key, data]，key为记录的键值，对于不同数据记录，key是互不相同的；data为数据记录除key外的数据。
• 前面讲过，由于B树不适合于大范围查询操作，因此B+树中多了个指针，当需要做范围查询时，只需要定位第一个节点，然后就可以直接根据各节点之间的指针，获取到对应范围之内的所有节点，也就是只需要发生一次IO，就能够确定所查范围之内的所有数据位置。在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的B+Tree。例如图中如果要查询key为从18到49的所有数据记录，当找到18后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。

那么hash结构呢？

hash索引虽然有上面谈到的时间复杂度的优势，并且相比b+树在空间复杂度上也存在优势，但是没有被广泛应用，主要有如下缺点:

1. 查询性能受hash冲突率影响，性能不稳定
2. 只能通过等值匹配的方式查询，不能范围查询
3. 结构存储上没有顺序，查询时排序无法支持

我们可以查看存储引擎，也有支持hash索引的：

3.为什么b+树比b树更适合做索引

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

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

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

四、MYSQL索引实现

在MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的，本文主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式。

1.MyISAM索引实现（非聚簇）

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。下图是MyISAM索引的原理图：

这里设表一共有三列，假设我们以Col1为主键，则上图是一个MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引文件仅仅保存数据记录的地址。在MyISAM中，主索引和辅助索引（Secondary key）在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。如果我们在Col2上建立一个辅助索引，则此索引的结构如下图所示：

同样也是一颗B+Tree，data域保存数据记录的地址。因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

MyISAM的索引方式也叫做“非聚集”的。最大特点是将索引Page和数据Page分离。

如果我们创建一个存储引擎为MyISAM的表，在var/lib/mysql下会增加对应的文件：

 mtest.frm --表结构数据
 mtest.MYD --该表对应的数据，当前没有数据，大小为0
 mtest.MYI --该表对应的主键索引数据

2.InnoDB索引实现（聚簇）

虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。

第一个重大区别是InnoDB的数据文件本身就是索引文件。从上文知道，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。

上图是InnoDB主索引（同时也是数据文件）的示意图，可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。

第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。下图为定义在Col3上的一个辅助索引：

这里以英文字符的ASCII码作为比较准则。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。

了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助，例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。再例如，用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。

如果我们创建一个存储引擎为InnoDB的表，在var/lib/mysql下会增加对应的文件：

itest.frm --表结构数据
itest.ibd --该表对应的主键索引和用户数据，现在没数据，但表大小不为0，因为有主键索引数据

五、索引操作

1.主键索引

创建主键索引的方式有如下三种：

-- 在创建表的时候，直接在字段名后指定 primary key
create table user1(id int primary key, name varchar(30));

-- 在创建表的最后，指定某列或某几列为主键索引
create table user2(id int, name varchar(30), primary key(id));

create table user3(id int, name varchar(30));
-- 创建表以后再添加主键
alter table user3 add primary key(id);

主键索引的特点：

1. 一个表中，最多有一个主键索引，当然可以使复合主键
2. 主键索引的效率高（主键不可重复）
3. 创建主键索引的列，它的值不能为null，且不能重复
4. 主键索引的列基本上是int

2.唯一索引

创建唯一索引也有三种方式：

-- 在表定义时，在某列后直接指定unique唯一属性。
create table user4(id int primary key, name varchar(30) unique);

-- 创建表时，在表的后面指定某列或某几列为unique
create table user5(id int primary key, name varchar(30), unique(name));

create table user6(id int primary key, name varchar(30)）；
alter table user6 add unique(name);

唯一索引的特点：

1. 一个表中，可以有多个唯一索引
2. 查询效率高
3. 如果在某一列建立唯一索引，必须保证这列不能有重复数据
4. 如果一个唯一索引上指定not null，等价于主键索引

3.普通索引

创建普通索引的三种方式：

create table user8(id int primary key,
	name varchar(20),
	email varchar(30),
	index(name) --在表的定义最后，指定某列为索引
);

create table user9(id int primary key, name varchar(20), email varchar(30));
alter table user9 add index(name); --创建完表以后指定某列为普通索引

create table user10(id int primary key, name varchar(20), emailvarchar(30));
-- 创建一个索引名为 idx_name 的索引
create index idx_name on user10(name);

普通索引的特点：

1. 一个表中可以有多个普通索引，普通索引在实际开发中用的比较多
2. 如果某列需要创建索引，但是该列有重复的值，那么我们就应该使用普通索引

4.全文索引

当对文章字段或有大量文字的字段进行检索时，会使用到全文索引。MySQL提供全文索引机制，但是有要求，要求表的存储引擎必须是MyISAM，而且默认的全文索引支持英文，不支持中文。如果对中文进行全文检索，可以使用sphinx的中文版(coreseek)。

创建方式：

CREATE TABLE articles (
	id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
	title VARCHAR(200),
	body TEXT,
	FULLTEXT (title,body)
)engine=MyISAM;

//并插入以下数据
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 ...');

用常规查询语句，我们发现并没有用到索引：

那么索引应该怎么去使用呢？

5.查询、删除索引

查询索引：

show keys from 表名

show index from 表名;

desc 表名

删除索引：

第一种方法-删除主键索引： alter table 表名 drop primary key;

第二种方法-其他索引的删除： alter table 表名 drop index 索引名； 
索引名就是show keys from 表名中的 Key_name 字段

第三种方法方法： drop index 索引名 on 表名

索引创建的原则：

1. 比较频繁作为查询条件的字段应该创建索引
2. 唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件
3. 更新非常频繁的字段不适合作创建索引
4. 不会出现在where子句中的字段不该创建索引