目录
索引简述与背景
索引：
提高数据库的性能，索引是物美价廉的东西了。
不用加内存，不用改程序，不用调sql，只要执行正确的 create index ，查询速度就可能提高成百上千倍。
但是天下没有免费的午餐，查询速度的提高是以插入、更新、删除的速度为代价的，这些写操作，增加了大量的IO。所以索引的价值，在于提高一个海量数据的检索速度。
常见的索引分为:
- 主键索引(primary key)
- 唯一索引(unique)
- 普通索引(index)
- 全文索引(fulltext)–解决子文索引问题。
我们需要从硬件角度，系统角度，应用角度（MySQL是一个应用，其进行IO的起本单位是1page<=>16KB）才能全方位的理解索引
认识磁盘
MySQL与存储
- MySQL 给用户提供存储服务，而存储的都是数据，数据在磁盘这个外设当中。
- 磁盘是计算机中的一个机械设备，相 比于计算机其他电子元件，磁盘效率是比较低的，在加上IO本身的特征，可以知道，如何提交效率，是 MySQL 的一 个重要话题。
下面是磁盘中的一个盘片:
![]](https://img-blog.csdnimg.cn/98096f6c9ee44b49be9c7d2d165ac230.png)
扇区
数据库文件，本质其实就是保存在磁盘的盘片当中。也就是上面的一个个小格子中，就是我们经常所说的扇区。
当然，数据库文件很大，也很多，一定需要占据多个扇区。
所以，最基本的，找到一个文件的全部，本质，就是在磁盘找到所有保存文件的扇区。
而我们能够定位任何一个扇区，那么便能找到所有扇区，因为查找方式是一样的。
系统的IO交互
我们现在已经能够在硬件层面定位，任何一个基本数据块了(扇区)。
那么在系统软件上，就直接按照扇区(512字节， 部分4096字节),进行IO交互吗？不是
-
如果操作系统直接使用硬件提供的数据大小（512字节）进行交互，那么系统的IO代码，就和硬件强相关，换言之，如果硬件发生变化，系统必须跟着变化，耦合度太高;
-
从目前来看，单次IO 512字节，还是太小了。IO单位小，意味着读取同样的数据内容，需要进行多次磁盘访问，会带来效率的降低。
-
之前学习文件系统，就是在磁盘的基本结构下建立的，文件系统读取基本单位，就不是扇区，而是数据块(文件i节点可以证明)。
故，系统读取磁盘，是以块为单位的，基本单位是 4KB 。
磁盘随机访问(Random Access)与连续访问(Sequential Access)
- 随机访问：本次IO所给出的扇区地址和上次IO给出扇区地址不连续，这样的话磁头在两次IO操作之间需要作比较大 的移动动作才能重新开始读/写数据。
- **连续访问：**如果当次IO给出的扇区地址与上次IO结束的扇区地址是连续的，那磁头就能很快的开始这次IO操作，这 样的多个IO操作称为连续访问。
磁盘是通过机械运动(磁头旋转等)进行寻址的，连续访问不需要过多的定位，故效率比较高。
MySQL 与磁盘交互基本单位
而 MySQL 作为一款应用软件，可以想象成一种特殊的文件系统。它有着更高的IO场景，所以，为了提高基本的IO效 率， MySQL 进行IO的基本单位是 16KB (后面统一使用 InnoDB 存储引擎讲解)
mysql> SHOW GLOBAL STATUS LIKE 'innodb_page_size'; -- 查看innodb与磁盘交互单位大小
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Innodb_page_size | 16384 | -- 16kb*1024=16384字节
+------------------+-------+
1 row in set (0.01 sec)
也就是说，磁盘这个硬件设备的基本单位是 512 字节**，而 MySQL InnoDB引擎 使用 16KB 进行IO交互。**
即， MySQL 和 磁盘进行数据交互的基本单位是 16KB 。这个基本数据单元，在MySQL 这里叫做page（注意和系统的page 512字节的区分）
用page交互的原因和系统一样，也是一种缓存池的机制，不然查一条就要IO一下，效率也太低下了！
MySQL 服务启动后创建Buffer Pool
类似于一个缓冲区，我们上面讲的其page(16KB)，就会一个一个在这个Buffer Pool中进行管理(与系统进行IO); 一般这个Buffer Pool，100多MB;
建立共识
- MySQL 中的数据文件，是以系统page为单位保存在磁盘当中的;
- MySQL 的 CURD 操作，都需要通过计算，找到对应的插入位置，或者找到对应要修改或者查询的数据。(相当于操作系统和底层硬件的一种解耦)
- 而只要涉及计算，就需要CPU参与，而为了便于CPU参与，一定要能够先将数据移动到内存当中。
- 所以在特定时间内，数据一定是磁盘中有，内存中也有。后续操作完内存数据之后，以特定的刷新策略，刷新 到磁盘。而这时，就涉及到磁盘和内存的数据交互，也就是IO了。而此时IO的基本单位就是mysql Page。
- 为了更好的进行上面的操作， MySQL 服务器在内存中运行的时候，在服务器内部，就申请了被称为 Buffer Pool 的的大内存空间，来进行各种缓存。其实就是很大的内存空间，来和磁盘数据进行IO交互。
- 为何更高的效率，一定要尽可能的减少系统和磁盘IO的次数；
索引详解
当我们向一个表中插入多条数据，并查看插入结果,如下:
-- 插入多条记录，注意，我们并没有按照主键id的大小顺序插入哦
mysql> insert into user (id, age, name) values(3, 18, '杨过');
Query OK, 1 row affected (0.01 sec)
mysql> insert into user (id, age, name) values(4, 16, '小龙女');
Query OK, 1 row affected (0.00 sec)
mysql> insert into user (id, age, name) values(2, 26, '黄蓉');
Query OK, 1 row affected (0.01 sec)
mysql> insert into user (id, age, name) values(5, 36, '郭靖');
Query OK, 1 row affected (0.00 sec)
mysql> insert into user (id, age, name) values(1, 56, '欧阳锋');
Query OK, 1 row affected (0.00 sec)
mysql> select * from user; -- 查看结果，发现竟然默认是有序的！是谁干的呢？排序有什么好处呢？
+----+-----+-----------+
| id | age | name |
+----+-----+-----------+
| 1 | 56 | 欧阳锋 |
| 2 | 26 | 黄蓉 |
| 3 | 18 | 杨过 |
| 4 | 16 | 小龙女 |
| 5 | 36 | 郭靖 |
+----+-----+-----------+
5 rows in set (0.00 sec)
答案:
MySQL缓冲区的每个page 16kb，决定了插入的记录会被自动排序！
理解单个Page
MySQL 中要管理很多数据表文件，而要管理好这些文件，就需要 先描述，在组织 ,我们目前可以简单理解成一个个独立文件是由一个或者多个(该文件比较大)Page构成的。
不同的 Page ，在 MySQL 中，都是 16KB ，使用 prev 和 next 构成双向链表
因为有主键的原因， MySQL 会默认按照主键给我们的数据进行排序，从上面的Page内数据记录可以看出，数据是有序且彼此关联的。
页内部存放数据的模块，实质上也是一个链表的结构，链表的特点也就是增删快（记录的增删数据库中常用），查询修改慢，所以优化查询的效率是必须 的。
正式因为有序，在查找的时候，从头到后都是有效查找，没有任何一个查找是浪费的，而且，如果运气好，是可以提前结束查找过程的。
因此，插入数据时排序的目的，就是优化查询的效率(存在页目录等优化手段，要求必须排序)
理解多个Page
- 通过上面的分析，我们知道，上面页模式中，只有一个功能，就是在查询某条数据的时候直接将一整页的数据加载到内存中，以减少硬盘IO次数，从而提高性能。 但是，我们也可以看到，现在的页模式内部，实际上是采用了链表的结构，前一条数据指向后一条数据，本质上还是通过数据的逐条比较来取出特定的数据。
- 如果有1千万条数据，一定需要多个Page来保存1千万条数据，多个Page彼此使用双链表链接起来，而且每个 Page内部的数据也是基于链表的。那么，查找特定一条记录，也一定是线性查找。这效率也太低了。 下面引入页目录进一步优化;
引入页目录
我们日常看书的时候，页号都是连续的，需要找某一章节的内容，我们可以通过前面的目录部分，快速定位页号，进而直接跳转过去，优化效率;
- 本质上，书中的目录，是多花了纸张的，但是却提高了效率
- 所以，目录，是一种“空间换时间的做法”
单页情况
那么当前，在一个Page内部，我们引入了目录。比如，我们要查找id=4记录，之前必须线性遍历4次，才能拿到结 果。
现在直接通过目录2[3]，直接进行定位新的起始位置，提高了效率。现在我们可以再次正式回答上面的问题了， 为何通过键值 MySQL 会自动排序？
- 方便引入目录，提高查找效率!
多页情况（浮现B+树）
MySQL 中每一页的大小只有 16KB ，单个Page大小固定，所以随着数据量不断增大，1页 16KB 不可能存下所有的数据， 那么必定会有多个页来存储数据。
单表数据不断被插入的情况下， MySQL 会在容量不足的时候，自动开辟新的Page来保存新的数据，然后通过指针的方式，将所有的Page组织起来。
这样，我们就可以通过多个Page遍历，Page内部通过目录来快速定位数据。
可是，貌似这样也有效率问题，在Page 之间，也是需要 MySQL 遍历的，遍历意味着依旧需要进行大量的IO，将下一个Page加载到内存，进行线性检测。这 样就显得我们之前的Page内部的目录，有点杯水车薪（有优化，但是不够用）了
- 那么如何解决呢？解决方案，其实就是我们之前的思路，给Page也带上目录。
- 使用一个目录项来指向某一页，而这个目录项存放的就是将要指向的页中存放的最小数据的键值（key，addr）。
- 与页内目录不同的地方在于，这种目录管理的级别是页（page），而页内目录管理的级别是行（记录）。
- 其中，每个目录项的构成是：键值+指针。图中没有画全;
存在一个目录页来管理页目录，目录页中的数据存放的就是指向的那一页中最小的数据。有数据，就可通过比较，找到该访问那个Page，进而通过指针，找到下一个Page，不需要挨着遍历page寻找了。
其实目录页的本质也是页，普通页中存的数据是用户数据（记录），而目录页中只存放普通页的key与addr。
- 可是，我们每次检索数据的时候，该从哪里开始呢？虽然顶层的目录页少了，但是还要遍历啊？ 不用担心，可以再网上累加目录页;
这就是传说中的B+树！至此，我们已经给我们的表user构建完了主键索引。
现在随便找一个id=？我们发现，现在查找的Page数一定减少了，也就意味着mysql与OS的IO次数减少了，那么效率也就提高了。
B+树总结
- Page分为目录页和数据页。目录页 只放各个下级Page的最小键值，数据页存放 key与 数据记录。
- 查找的时候，自顶向下找，只需要加载部分目录页到内存，即可完成算法的整个查找过程，大大减少了IO次数
目录页大小也是16KB，按照key：addr总共16字节来算，（16kb*1024）/16 = 1000多个;
这意味着一个目录页一个page，只存各个下级Page的最小键值能存1000多个！ 也就是1000多个page，每个page平均一下少说也能放300多条记录，那么倒数第二级的一个目录页就能管300*1000 = 300000多条记录，可见一般场景，B+树的整体形态会很矮胖，一般算上最下面一层，三层足以构建完成（第一层只有一个入口root page）;
也正式B+树的矮胖，意味着我们IO的page次数大大降低，大大提高了查询效率;
***其他数据结构为何不适用于索引？
- 链表？线性遍历啊
- 二叉搜索树？插入顺序，退化成链表问题，可能退化成为线性结构;
- AVL &&红黑树？虽然是平衡或者近似平衡，但是**毕竟是二叉结构，相比较多叉的B+，意味着树整体过高，大家都是自顶向下找，层高越低，意味着系统与硬盘更少的IO Page交互。**虽然你很秀，但是有更秀的。
Hash？
官方的索引实现方式中， MySQL 是支持HASH的，不过 InnoDB 和 MyISAM 并不支持. （下面的BTREE其实是 B+树;）
Hash跟进其算法特征，决定了虽然有时候也很快(O(1))，不过，在hash面对范围查找就明显不行（hash冲突这些，注定了数据的排序问题，面对一段范围的数据效率就低下了）; 还有哈希索引不支持多列联合索引的最左匹配规则，也是排序性导致的原因;
B树 VS B+树
B+树：
B树？(如下图，每个节点既有index又有value，且之后的节点index不重复出现，且叶子节点相互不连接)
区别:
- **节点: ** B树节点，既有数据，又有Page指针； 而B+,只有叶子节点有数据，其他目录页，只有键值和Page指针
- 叶子节点: B+叶子节点，全部左右相连，而B没有相连;
为何选择B+:
-
B树缺点: 说白了，目录页如果存放key+data的话(B B+的区别1)，整体树高度会变高，降低page io的效率;
-
而且B树的节点之间没有双向连接(B B+的区别2)，那么一段范围的数据查询，如果存在多个连续的page中，不能像B+一样直接prev或者next找过去，而是又得从root向下找对应的page，效率不高;
B树优点 ： B树的每一个结点都包含key(索引值) 和 value(对应数据)，因此方位离根结点近的元素会更快速。（相对于B+树）
聚簇索引 VS 非聚簇索引
MyISAM 存储引擎-主键索引
MyISAM 引擎同样使用B+树作为索引结果，叶节点的data域存放的是数据记录的地址。下图为 MyISAM 表的主索引， Col1 为主键。
其中， MyISAM 最大的特点是，将索引Page和数据Page分离，也就是叶子节点没有数据，只有对应数据的地址。
相较于 InnoDB 索引， InnoDB 是将索引和数据放在一起的。
查看MyISAM存储引擎下，创建一个表，对应的的文件:
- 其中， MyISAM 这种用户数据 与 索引分离的索引方案，叫做非聚簇索引
查看INNODB存储引擎下，创建一个表，对应的的文件:
- 其中， InnoDB 这种用户数据与索引数据在一起索引方案，叫做聚簇索引
主键索引VS普通索引
当然， MySQL 除了默认会建立主键索引外，我们用户也有可能建立按照其他列信息建立的索引，一般这种索引可以 叫做辅助（普通）索引[比如用户经常用的某个普通字段，那么我们就可以用这个字段建立索引提高查询效率]。
-
对于 MyISAM ,建立辅助（普通）索引和主键索引没有差别，无非就是主键不能重复，而非主键可重复; 叶子data部分保存的都是真正记录的地址
-
而对于 INNODB，建立辅助（普通）索引，可以看到， InnoDB 的非主键索引中叶子节点并没有数据，而只有对应记录的key值（用于下一步回表查询）。
所以INNODB通过辅助（普通）索引，找到目标记录，需要两遍索引：首先检索辅助索引获得主键（innodb的索引特殊性，即便没有主键，也会默认生成），然后用主键到主索引中检 索获得记录。这种过程，就叫做回表查询;但不是innodb每次查询都需要回表:
有时候复合索引常用，比如(key1,key2)的索引，我们用key2索引查询key1的时候，这时候查询的字段在索引中已经能拿到了，就不需要回表查询了！
- 为何 InnoDB 针对这种辅助（普通）索引的场景，不给叶子节点也附上数据呢？–>原因就是太浪费空间了,不可能每个普通索引，都需要吧表所有的data拷贝一份，那这么多重复记录可就太冗余了。
创建索引
创建主键索引
- 有主键就行，mysql就会自动创建主键索引;
-- 方法1.在创建表的时候，直接在字段名后指定 primary key
create table user1(id int primary key, name varchar(30));
-- 方法2.在创建表的最后，指定某列或某几列为主键索引
create table user2(id int, name varchar(30), primary key(id));
-- 方法3. 创建表以后再添加主键
create table user3(id int, name varchar(30));
alter table user3 add primary key(id);
主键索引特点:
- 一个表中，最多有一个主键索引，当然可以使符合主键
- 主键索引的效率高（主键不可重复)
- 创建主键索引的列，它的值不能为null，且不能重复
- 主键索引的列基本上是int
唯一索引的创建
- 有唯一键就行，mysql就会自动创建主键索引;
-- 1.在表定义时，在某列后直接指定unique唯一属性。
create table user4(id int primary key, name varchar(30) unique);
-- 2. 创建表时，在表的后面指定某列或某几列为unique
create table user5(id int primary key, name varchar(30), unique(name));
-- 3
create table user6(id int primary key, name varchar(30)）；
alter table user6 add unique(name);
唯一索引特点:
- 一个表中，可以有多个唯一索引
- 查询效率高(不重复)
- 如果在某一列建立唯一索引，必须保证这列不能有重复数据;
- 如果一个唯一索引上指定not null，等价于主键索引（索引层面的等价; 但是唯一键作为指定的一种唯一属性，与用于区分全表记录的主键还是不同的概念）
普通索引的创建
- 普通索引就需要 index（字段）显示创建啦;
-- 方法1
create table user8(id int primary key,
name varchar(20),
email varchar(30),
index(name) -- 在表的定义最后，指定某列为索引
);
-- 方法2
create table user9(id int primary key, name varchar(20), email varchar(30));
alter table user9 add index(name); -- 创建完表以后指定某列为普通索引
-- 方法3
create table user10(id int primary key, name varchar(20), email varchar(30));
create index idx_name on user10(name);-- 创建一个索引名为 idx_name 的索引
普通索引的特点：
- 一个表中可以有多个普通索引，普通索引在实际开发中用的比较多;（比如qq名字，就不是主键也不是唯一键，可以重复！但我们也经常用类似这样的普通索引查找）
- 如果某列需要创建索引，但是该列有重复的值，那么我们就应该使用普通索引
索引创建原则
- 比较频繁作为查询条件的字段应该创建索引;
- 唯一性太差的字段不适合单独创建索引（即使频繁作为查询条件）; eg:性别，非难即女，作为索引有啥用呢，提高不了效率;
- 更新非常频繁的字段不适合作创建索引; eg:索引的更新调整也是需要消耗时间的！
- 不会出现在where子句中的字段不该创建索引 eg：都不会出现where,用来筛选记录，还给他创建提高筛选效率的索引干嘛？
查询索引
show index from goods\G;
*********** 1. row ***********
Table: goods -- 表名
Non_unique: 0 -- 0表示唯一索引
Key_name: PRIMARY -- 主键索引
Seq_in_index: 1
Column_name: goods_id -- 索引在哪列
Collation: A
Cardinality: 0
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE -- 以B+树形式的索引
Comment:
1 row in set (0.00 sec)
删除索引
-- 方法一：删除主键索引
alter table 表名 drop primary key;
-- 方法一：删除唯一索引 or 其他索引
alter table 表名 drop index 索引名；
常见其他索引概念
复合索引
将数据库中的多个字段组合起来形成的一个索引就是复合索引。
-- 创建一个 复合的 唯一索引
UNIQUE key 'idex_test'('name','age') USING BTREE.
- 使用复合索引的目的: 能够形成索引覆盖，提高where查询的效率 （但注意，并不是越多越好，更新数据会更新索引，有代价的）
- 复合索引 一个充当好几种索引。index (a,b,c)为例建立这样的索引相当于建立了索引a、ab、abc三个索引。 一个索引顶三个索引当然是好事，毕竟每多一个索引，都会增加写操作的开销和磁盘空间的开销
索引覆盖
覆盖索引是一种数据查询方式;
在索引中，通过索引值可以直接找到要查询字段的值，而不需要通过主键值回表查询，那么就叫覆盖索引; ，
类似于INNODB中使用复合索引(name,age);
我们查询 select name, age from user where name = ‘xxx’; 那么liudehua匹配到(name,age)中的name时候，进而匹配到(name,age)索引，不需要拿到对应的主键key回表查询，也能拿到需要查询的age,就不用再回表查询了–>索引覆盖;
索引最左匹配原则
在SQL语句中，复合索引的第一个字段必须出现查询语句中，这样索引才能够被使用。否则，最左字段不出现在where的查询语句，则不会走索引;(explain 关键字可证明;)explain显示了mysql如何使用索引来处理select语句以及连接表的相关信息
- mysql创建联合索引时，首先会对最左边字段排序，也就是第一个字段，然后再在保证第一个字段有序的情况下，再排序第二个字段，多字段顺序以此类推。
10万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
