查询利器—索引

目录

索引的优缺点

常见索引分类

MySQL数据操作的宏观过程

认识磁盘

正式理解索引结构

采用B+树的原因

聚簇索引与非聚簇索引

索引操作

索引创建原则

---

索引的优缺点

优点：提高一个海量数据的检索速度 

缺点：查询速度的提高是以插入、更新、删除的速度为代价的，这些写操作，增加了大量的IO

创建索引前

创建索引后

常见索引分类

主键索引(primary key)

唯一索引(unique)

普通索引(index)

全文索引(fulltext)--解决中子文索引问题

MySQL数据操作的宏观过程

MySQL对数据做的CURD(增删查改)操作，根据冯诺依曼体系，MySQL不可能直接去访问磁盘

实际上，数据库中对数据做的所有的访问，全部都是在内存中进行的

MySQL也会定期的将数据刷新到磁盘中！

如下图，能通过调用syncfs接口将内核缓冲区中的数据手动刷新到磁盘，也能系统自动刷新！

认识磁盘

目前我们认为，每个扇区的默认大小为512B

磁头（Heads）、柱面(Cylinder)(等价于磁道)、扇区(Sector)对应的编号。即可在磁盘上定位所要

访问的扇区，这种磁盘数据定位方式叫做 CHS

系统软件使用的并不是CHS，而是LBA，LBA ，一种线性地址，可以想象成虚拟地址与物理地

址， 系统将 LBA 地址最后会转化成为 CHS ，交给磁盘去进行数据读取

系统软件与IO交互的基本单位并不是512B，而是4KB ，原因如下：

如果操作系统直接使用硬件提供的数据大小进行交互，那么系统的IO代码，就和硬件强相关，换言

之，如果硬件发生变化，系统必须跟着变化

从目前来看，单次IO 512字节，还是太小了。IO单位小，意味着读取同样的数据内容，需要进行多

次磁盘访问，会带来效率的降低

随机访问：本次IO所给出的扇区地址和上次IO给出扇区地址不连续，这样的话磁头在两次IO操作

之间需要作比较大的移动动作才能重新开始读/写数据

连续访问：如果当次IO给出的扇区地址与上次IO结束的扇区地址是连续的，那磁头就能很快的开始

这次IO操作，这样的多个IO操作称为连续访问

系统中一定存在大量的IO请求，那么操作系统就需要管理这些IO请求，管理方式：先描述，再组织

MySQL和磁盘进行数据交互的基本单位是16KB，这个基本数据单元，在 MySQL 这里叫做page

（注意和系统的page区分）

为何IO交互要是 Page，而不是用多少，加载多少不好吗？

如果MySQL要查找id=2的记录，第一次加载id=1，第二次加载id=2，一次一条记录，那么就需要2

次IO，如果要找id=5，那么就需要5次IO！

如果这5条(或者更多)都被保存在一个Page中(16KB，能保存很多记录),那么第一次IO查找id=2的

时 候，整个Page会被加载到MySQL的Buffer Pool中，这里完成了一次IO，但是往后如果在查找

id=1,3,4,5等，完全不需要进行IO了，而是直接在内存中进行了，这样就减少了IO的次数！

虽然无法保证用户下次找到的数据就在这个Page里，但是有很大概率！因为有局部性原理！！！

IO效率低下的最主要矛盾不是IO单次数据量的大小，而是IO的次数

建立共识

MySQL 中的数据文件，是以page为单位保存在磁盘当中的

MySQL 的 CURD 操作，都需要通过计算，找到对应的插入位置，或者找到对应要修改或者查询

的 数据

只要涉及计算，就需要CPU参与，而为了便于CPU参与，一定要能够先将数据移动到内存当中

在特定时间内，数据一定是磁盘中有，内存中也有。后续操作完内存数据之后，以特定的刷新策

略，刷新到磁盘

为了更好的进行上面的操作， MySQL 服务器在内存中运行的时候，在服务器内部，就申请了被称

为 Buffer Pool 的的大内存空间，来进行各种缓存

为了更高的效率，一定要尽可能的减少系统和磁盘IO的次数

正式理解索引结构

MySQL中，在任何一个时刻，一定会存在大量的Page页存在于MySQL内部，MySQL本身就要对

它的Page进行管理，先描述，再组织！

如下图，在user表中插入以下数据后，会自动按 id (主键属性列)排好序

单个Page

现在的页模式内部，实际上是采用了链表的结构，前一条数据指向后一条数据，本质上还是通过数

据的逐条比较来取出特定的数据，效率太低了！

如何提高在一个页内进行搜索的效率

用创作书籍的方式，添加目录！即以空间换时间！

为什么要排好序

因为按照主键属性列排好序后，可以很方便的引入目录！！！

多个Page

一个Page只有16kb的空间，数据量不断增大时，就得添加新的Page页来存储数据，可当我们查找

数据时，虽然Page内部有目录，但是Page之间还是通过双链表连接的，也存在效率问题，在

Page 之间，也是需要 MySQL 遍历的，遍历意味着依旧需要进行大量的IO，将下一个Page加载到

内 存，进行线性检测

如何提高多个Page查找数据的效率

类似于单个Page的做法，也给Page也带上目录！！！

如下图所示，以第二行为例，该行的一个Page中存储的都是第三行每个Page 最小的id，除了最后

一层存储数据外，其余层都只存放目录！！！也就形成了下图中的B+树结构！

Page分为目录页和数据页。目录页只放各个下级Page的最小键值

目录页的本质也是页，普通页中存的数据是用户数据，而目录页中存的数据是普通页的地址

查找的时候，自顶向下找，只需要加载部分目录页到内存，不需要太多的加载无效的Page，即可

完成算法的整个查找过程，大大减少了IO次数

什么是主键索引

所有的数据最终可以在磁盘中，也可以在MySQL的buffer pool内存中

所有的数据都必须以Page 为单位进行IO，以Page为单位进行组织

在MySQL内部，将热点数据，以B+树的形式将所有的Page页，进行组织，形成的数据结构与其

配套的查找算法，叫做索引！

采用B+树的原因

InnoDB 在建立索引结构来管理数据的时候，其他数据结构为何不行

链表，线性遍历，查询效率太低；二叉树搜索树，可能会退化成为线性结构；AVL和红黑树，因为

是二叉结构，树整体过高，因为是自顶向下查找，层高越高，意味着系统与硬盘会更多的IO Page

交互；Hash结构，因为是散列的，比如在查找数学成绩在60-80分的同学时，效率就不够高了！

为什么不选择B树，而选择B+树

B树节点，既有数据，又有Page指针，而B+，只有叶子节点有数据，其他目录页，只有键值和

Page指针，所以对于B+树，一个节点可以存储更多的key，使得树更矮，IO操作次数更少

B+叶子节点，全部相连，而B没有，所以B+树更便于进行范围查找

B+树在哪里

在磁盘上有完整的B+树和数据，在内存中有局部高频被访问的B+树的核心Page，MySQL查找一

定会伴生着MySQL根据B+树进行Page的换入换出！

MySQL其实就是一个文件系统！！！

聚簇索引与非聚簇索引

下图为 MyISAM 表的主索引，Col1 为主键，将索引Page和数据Page分离，叶子节点没有 数据，

只有对应数据的地址，MyISAM 这种用户数据与索引数据分离的索引方案，叫做非聚簇引

如下图，创建了一个表格，存储引擎为MYISAM，建好后就有了右边的三个文件，frm是表结构，

MYD是数据，MYI是主键索引数据

InnoDB 这种用户数据与索引数据在一起索引方案，叫做聚簇索引

除了主键索引外，还有辅助(普通)索引，唯一区别在于，主键不能重复，而非主键可重复

如下图，InnoDB 的非主键索引中叶子节点并没有数据，而只有对应记录的key值

通过辅助（普通）索引，找到目标记录，需要两遍索引：首先检索辅助索引获得主键，然后用主键

到主索引中检索获得记录，这种过程，就叫做回表查询

对于普通索引，不给叶子节点附上数据，是因为太浪费空间了！

索引操作

创建主键索引

方式一：在创建表的时候，直接在字段名后指定 primary key

方式二：在创建表的最后，指定某列或某几列为主键索引

例：create table user2(id int, name varchar(30), primary key(id));

方式三：创建表后添加索引

例：alter table user3 add primary key(id);

查询索引

show index from 表名;

注意：下图中的BTREE不是B树，而是B+树！！！

另外两种方式则是：

show keys from 表名；

desc 表名；

创建唯一键索引

方式一：在表定义时，在某列后直接指定unique唯一属性

方式二：创建表时，在表的后面指定某列或某几列为unique

例：create table user5(id int primary key, name varchar(30), unique(name));

方式三：创建表后添加唯一键索引

例：alter table user6 add unique(name); 

创建普通索引

方式一：在表的定义最后，指定某列为索引

方式二：创建完表以后指定某列为普通索引

例：alter table user9 add index(name);

方式三：创建一个索引名为 idx_name 的索引

例：create index idx_name on user10(name);

删除索引

删除主键索引：alter table 表名 drop primary key;

其他索引的删除： alter table 表名 drop index 索引名； 索引名就是show keys from 表名中的

Key_name 字段

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

全文索引的创建

当对文章字段或有大量文字的字段进行检索时，会使用到全文索引。MySQL提供全文索引机制，

但是有要求，要求表的存储引擎必须是MyISAM，而且默认的全文索引支持英文，不支持中文，

如果对中文进行全文检索，可以使用sphinx的中文版(coreseek)

如下图，创建一个全文索引的表格，以及插入数据

查询有没有database数据 

explain可以查看细节，key为NULL，表示没有采用全文索引的方式

采用全文索引

注意：key为title，并不是只用到了表格列title，而是索引的名称为title

索引创建原则

比较频繁作为查询条件的字段应该创建索引

唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件

更新非常频繁的字段不适合作创建索引

不会出现在where子句中的字段不该创建索引