MySQL二、索引及对应数据结构

目录

Data Structure Visualization 各种数据结构的动态演示

一、索引到底是什么

a. 索引图解

百科内容：

数据库索引，是数据库管理系统(DBMS)中一个排序的数据结构，以协助快速查询、更新数据库表中的数据。

首先数据是以文件形式存储在磁盘上的，每一行数据都有它的磁盘地址。如果没有索引的话，要从500万行数据里面检索一条数据，只能依次遍历这张表的全部数据，直到找到这条数据。
但是有了索引之后，只需要从索引里去检索这条数据，而索引本身是一种特殊的专门用来快速检索的数据结构，会相对快速的定位到索引，进而定位到数据的磁盘地址。
这就像从一本500页的书里去找特定一个小节，肯定不会从第一页开始翻，而是从目录开始查找。

b. 索引类型

创建一个索引，会指定索引名称、索引的列、索引类型以及索引方法。 在InnoDB存储引擎中，索引类型有三种：普通索引、唯一索性(主键索引是特殊的唯一索引)、全文索引。 普通索引(Normal)：也叫非唯一索引，是最普通的索引，没有任何的限制。 唯一索引(Unique)：唯一索引要求键值不能重复。主键索引是一种特殊的唯一索引，且多了一个键值不能为空的条件限制。主键索引用primary key创建。 全文索引(Full Text)：针对比较大的数据，比如我们存放的是消息内容，有几KB的数据，如果要解决Like查询效率低的问题，可以创建全文索引。只有文本类型的字段才可以创建全文索引，比如cahr、varchar、text。 
CREATE fulltext INDEX idx_comment ON blog (comment);

全文索引的使用：

SELECT * FROM blog  WHERE MATCH(`comment`) AGAINST('123')

MyISAM和InnoDB都支持全文索引。

二、MySQL索引数据模型

我们说索引是一种数据结构，那么它是一种什么样的数据结构？

1. 二分查找

双十一过去之后，女朋友和你玩了一个猜数字游戏。猜猜昨天买了多少钱，给你五次机会？
10000？低了。30000？高了。

接下来你会猜多少？ 正常情况，会猜20000。

其实这个就是二分查找的思想，也叫折半查找，每一次，我们都把候选数据缩小了一般。如果数据已经排过序，这种方式效率较高。
有序数组的等值查询和比较查询效率非常高，但是更新数据的时候回出现一个问题，可能要挪动大量的数据(改变index)，所以只适合存储静态的数据。
为了支持频繁的修改，比如插入数据，我们需要采用链表。链表的话，如果使用单向链表，它的查找效率还是不够高的。
那有没有使用二分查找的链表呢？

为了解决这个问题。BST(Binary Search Tree)也就是我们所说的二叉查找树诞生了。

2. 二叉查找树(BST Binary Search Tree)

二叉查找树特点：
左子树所有的节点都小于父节点，右子树所有的节点都大于父节点。投影到平面以后，就是一个有序的线性表。

二叉查找树既能实现快速查找，又能实现快速插入。但是二叉查找树有一个问题：
就是它的查找耗时是和这棵树的深度有关的，在最坏的情况下时间复杂度会退化成O(n)。

演示一下最坏的情况：
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
还是刚才的数字，插入顺序是有序的：2、6、11、13、17、22。
这个时候我们的二叉查找树变成了什么样了呢？
它会变成链表(这种树也叫作"斜树")，这种情况下不能达到加快检索速度的目的，和顺序查找效率是没有区别的。

造成他倾斜的原因是什么呢？
因为左右子树深度差太大，这棵树的左子树根本没有节点-也就是说它不够平衡。

所以，我们有没有左右子树深度相差不是那么大，有没有更加平衡的树呢？
这个就是平衡二叉树，叫做Balanced binary search trees，或者AVL树(AVL是发明这个数据结构的人的名字)。

3. 平衡二叉树(AVL Tree)(左旋、右旋)

AVL Trees(Balanced binary search trees)
平衡二叉树的定义：左右子树深度差绝对值不能超过1。比如左子树的深度是2，那么右子树的深度只能是1或者3.
此时 AVL Tree 演示，依次插入1、2、3、4、5、6，就不会变成一颗"斜树"了。

当我们插入节点1、2后，再插入3节点，此时会发现根节点1的左侧树深度为0，右侧子树深度为2，违反了平衡二叉树的定义，左右字数深度差绝对值不超过1。此时右子树深度为2，为右-右型，所以会把2提上去，这个操作叫做左旋。

同样的，如果我们是插入7、6、5，树结构会变成左左型，会发生右旋操作。

所以为了保持平衡，AVL树在插入和更新数据的时候执行了一系列的计算和调整的操作。
平衡的问题解决了，那么平衡二叉树作为索引怎么查询数据？
在平衡二叉树中，一个节点，它的大小是一个固定的单位，作为索引应该存储什么内容？
第一个是索引的键值。比如我们在id上面建立了一个索引，在用 where id=1的查询条件的时候就会找到数据结构里面id的这个键值。
第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。
第三个，因为是二叉树，会有左子节点和右子节点的引用，这样才能找到下一个节点。比如大于26的时候，走右边，到下一个树的节点，继续判断。

如果是这样存储数据的话，还会有什么问题？
在分析用 AVL 树存储索引数据之前，先来学习一下 InnoDB 的逻辑存储结构。

a. InnoDB逻辑存储结构

https://dev.mysql.com/doc/refman/8.0/en/innodb-file-space.html
MySQL的存储结构分为5级：表空间 Tablespaces、段 Segments、簇 Extents、页 Pages、行 Rows。

表空间 Tablespaces

表空间可以看做是 InnoDB 存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。分为：系统表空间、独占表空间、通用表空间、临时表空间、Undo 表空间。

段 Segment

表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等，段是一个逻辑的概念。一个 ibd 文件（独立表空间文件）里面会由很多个段组成。
创建一个索引会创建两个段，一个是索引段：leaf node segment，一个是数据段：no-leaf node segment。索引段管理非叶子节点的数据。数据段管理叶子节点的数据。也就是说，一个表的段数，就是索引的个数乘以 2。

簇 Extent

一个段（Segment）又由很多的簇（也可以叫区）组成，每个区的大小是 1MB（64个连续的页）。
每一个段至少会有一个簇，一个段所管理的空间大小是无限的，可以一直扩展下去，但是扩展的最小单位就是簇。

页 Pages

为了高效管理物理空间，对簇进一步细分，就得到了页。簇就是连续的页(Page)组成的空间，1页为16KB，那么一个簇总有64个连续的页(1MB/16KB=64)。这些页面在物理和逻辑上都是连续的。
跟大多数据库一样，InnoDB 也有页的概念（也可以称为块），每个页默认 16KB。页是 InnoDB 存储引擎磁盘管理的最小单位，通过 innodb_page_size 设置。
一个表空间最多拥有 2^32 个页，默认情况下一个页的大小为 16KB，也就是说一个表空间最多存储 64TB 的数据。
注意，文件系统中，也有页的概念。
操作系统和内存打交道，最小的单位是页 Page。文件系统的内存页通常是 4K。

mysql> show variables like 'innodb_page_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+

假设一行数据的大小是1K，那么一个数据页可以存放16行这样的数据。
例如：一个页放3行数据

往表中插入数据时，如果一个页面已经写完，产生一个新的叶页面。如果一个簇的所有的页面都被用完，会从当前页面所在段新分配一个簇。
如果数据不是连续的，往已经写满的页中插入数据，会导致叶页面分裂：

行 Rows

InnoDB 存储引擎是面向行的（row-oriented），也就是说数据的存放按行进行存放。
此篇文章目的是介绍索引的数据结构及存储，不再细说。

b. AVL数用于存储索引数据

首先，索引的数据，是放在硬盘上的。查看数据和索引的大小：

select A.DATA_LENGTH/1024/1024 as dataSize_MB, A.INDEX_LENGTH/1024/1024 as indexSize_MB, A.*
from information_schema.TABLES A
where table_schema='db_name' and table_name='blog';

当我们用树的结构来存储索引的时候，访问一个节点就要跟磁盘之间发生一次 IO。InnoDB 操作磁盘的最小的单位是一页（或者叫一个磁盘块），大小是 16K(16384 字节)。
那么，一个二叉树的节点就是 16K 的大小。
如果我们一个节点只存一个键值+数据磁盘地址+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远达不到 16K 的容量，所以访问一个树节点，进行一次 IO 的时候，浪费了大量的空间。
所以如果每个节点存储的数据太少，从索引中找到我们需要的数据，就要访问更多的节点，意味着跟磁盘交互次数就会过多。
如果是机械硬盘时代，每次从磁盘读取数据需要 10ms 左右的寻址时间，交互次数越多，消耗的时间就越多。

比如上面这张图，我们一张表里面有 6 条数据，当我们查询 id=37 的时候，要查询两个子节点，就需要跟磁盘交互 3 次，如果我们有几百万的数据呢？这个时间更加难以估计。
所以我们的解决方案是什么呢？
第一个就是让每个节点存储更多的数据。
第二个，节点上的关键字的数量越多，我们的指针数也越多，也就是意味着可以有更多的分叉（我们把它叫做“路数”）。因为分叉数越多，树的深度就会减少（根节点是 0）。
这样，我们的树是不是从原来的高瘦高瘦的样子，变成了矮胖矮胖的样子？

这个时候，我们的树就不再是二叉了，而是多叉，或者叫做多路。

4. 多路平衡查找树(B Tree)(分裂、合并)

Balanced Tree
这个就是我们的多路平衡查找树，叫做 B Tre（B 代表平衡）。
跟 AVL 树一样，B 树在枝节点和叶子节点存储键值、数据地址、节点引用。
它有一个特点：分叉数（路数）永远比关键字数多 1。比如我们画的这棵树，每个节点存储两个关键字，那么就会有三个指针指向三个子节点。

B Tre 的查找规则是什么样的呢？
比如我们要在这张表里面查找 15。
因为 15 小于 17，走左边。
因为 15 大于 12，走右边。
在磁盘块 7 里面就找到了 15，只用了 3 次 IO。
这个是不是比 AVL 树效率更高呢？
那 B Tree 又是怎么实现一个节点存储多个关键字，还保持平衡的呢？跟 AVL 树有什么区别？
https://www.cs.usfca.edu/~galles/visualization/BTree.html
比如 Max Degree（路数）是 3 的时候，我们插入数据 1、2、3，在插入 3 的时候，本来应该在第一个磁盘块，但是如果一个节点有三个关键字的时候，意味着有 4 个指针，子节点会变成 4 路，所以这个时候必须进行分裂。把中间的数据 2 提上去，把 1 和 3 变成 2 的子节点。
如果删除节点，会有相反的合并的操作。
注意这里是分裂和合并，跟 AVL 树的左旋和右旋是不一样的。
我们继续插入 4 和 5，B Tre 又会出现分裂和合并的操作。

从这个里面我们也能看到，在更新索引的时候会有大量的索引的结构的调整，所以解释了为什么我们不要在频繁更新的列上建索引，或者为什么不要更新主键。
节点的分裂和合并，其实就是 InnoDB 页的分裂和合并。

5. B+Tree (加强版多路平衡查找树)

B Tree 的效率已经很高了，为什么 MySQL 还要对 B Tree 进行改良，最终使用了B+Tree 呢？
总体上来说，这个 B 树的改良版本解决的问题比 B Tree 更全面。
我们来看一下 InnoDB 里面的 B+树的存储结构：

MySQL 中的 B+Tree 有几个特点：
1、它的关键字的数量是跟路数相等的；
2、B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索 id=28，虽然在第一层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点。
举个例子：假设一条记录是 1K，一个叶子节点（一页）可以存储 16 条记录。非叶子节点可以存储多少个指针？
假设索引字段是 bignt 类型，长度为 8 字节。指针大小在 InonDB 源码中设置为 6 字节，这样一共 14 字节。非叶子节点（一页）可以存储 16KB/14B = 16384/14= 1170 个这样的单元（键值+指针），代表有 1170 个指针。
树 深 度 为 2 的 时 候 ， 有 1170^2 个 叶 子 节 点 ， 可 以 存 储 的 数 据 为1170*1170*16=2190240。

在查找数据时一次页的查找代表一次 IO，也就是说，一张 20 万左右的表，查询数据最多需要访问 3 次磁盘。
所以在 InnoDB 中 B+ 树深度一般为 1-3 层，它就能满足千万级的数据存储。
3、B+Tree 的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。
4、它是根据左闭右开的区间 [ )来检索数据。

我们来看一下 B+Tree 的数据搜寻过程：
1）比如我们要查找 28，在根节点就找到了键值，但是因为它不是页子节点，所以会继续往下搜寻，28 是[28,6)的左闭右开的区间的临界值，所以会走中间的子节点，然后继续搜索，它又是[28,34)的左闭右开的区间的临界值，所以会走左边的子节点，最后在叶子节点上找到了需要的数据。
2）第二个，如果是范围查询，比如要查询从 22 到 60 的数据，当找到 22 之后，只需要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高了区间查询效率（不需要返回上层父节点重复遍历查找）。

总结一下，InnoDB 中的 B+Tree 的特点：
1)它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。B Tree 解决的两大问题是什么？（每个节点存储更多关键字；路数更多）
2)扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵 B+Tree 拿到所有的数据）
3) B+Tree 的磁盘读写能力相对于 B Tree 来说更强（根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘IO加载的关键字更多）
4)排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链表）
5)效率更加稳定（B+Tree 永远是在叶子节点拿到数据，所以 IO 次数是稳定的）

6.为什么不用红黑树？

红黑树也是 BST 树，但是不是严格平衡的。
必须满足 5 个约束：
1、节点分为红色或者黑色。
2、根节点必须是黑色的。
3、叶子节点都是黑色的 NUL 节点。
4、红色节点的两个子节点都是黑色（不允许两个相邻的红色节点）。
5、从任意节点出发，到其每个叶子节点的路径中包含相同数量的黑色节点。
插入：60、56、68、45、64、58、72、43、49

基于以上规则，可以推导出：
从根节点到叶子节点的最长路径（红黑相间的路径）不大于最短路径（全部是黑色节点）的 2 倍。
为什么不用红黑树？1、只有两路；2、不够平衡。
红黑树一般只放在内存里面用。例如 Java 的 TreeMap。

7.索引方式：真的是用的B+Tree吗？

在 Navicat 的工具中，创建索引，索引方式有两种，Hash 和 B Tree。
HASH：以 KV 的形式检索数据，也就是说，它会根据索引字段生成哈希码和指针，指针指向数据。

哈希索引有什么特点呢？
第一个，它的时间复杂度是 O(1)，查询速度比较快。因为哈希索引里面的数据不是按顺序存储的，所以不能用于排序。
第二个，我们在查询数据的时候要根据键值计算哈希码，所以它只能支持等值查询（= IN），不支持范围查询（> < >= <= betwen and）。
另外一个就是如果字段重复值很多的时候，会出现大量的哈希冲突（采用拉链法解决），效率会降低。

问题： InnoDB 可以在客户端创建一个索引，使用哈希索引吗？
InnoDB utilzes hash indexs internaly for its Adaptive Hash Index feature
直接翻译过来就是：InnoDB 内部使用哈希索引来实现自适应哈希索引特性。
这句话的意思是 InnoDB 只支持显式创建 B+Tree 索引，对于一些热点数据页，InnoDB 会自动建立自适应 Hash 索引，也就是在 B+Tree 索引基础上建立 Hash 索引，这个过程对于客户端是不可控制的，隐式的。
我们在 Navicat 工具里面选择索引方法是哈希，但是它创建的还是 B+Tree 索引，这个不是我们可以手动控制的。
前一章提到 buffer pool 里面有一块区域是 Adaptive Hash Index 自适应哈希索引，就是这个。
这个开关默认是 ON：

mysql> show variables like 'innodb_adaptive_hash_index';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_adaptive_hash_index | ON    |
+----------------------------+-------+

因为B Tree 和 B+Tree 的特性，它们广泛地用在文件系统和数据库中，例如Windows的 HPFS 文件系统，Oracel、MySQL、SQLServer 数据库

三、存储引擎中B+Tree如何落地？

1. MySQL架构

之前介绍过，MySQL是一个支持插件式存储引擎的数据库。在MySQL里面，每个表都可以在创建时指定它所使用的存储引擎，而且之后也可以修改。
需要我们主要关注的两个存储引擎：MyISAM和InnoDB的索引实现。

2. MySQL数据存储文件

首先，MySQL 的数据都是文件的形式存放在磁盘中的，我们可以找到这个数据目录的地址。在 MySQL 中有这么一个参数，我们来看一下：

mysql> show variables like 'datadir';
+---------------+---------------------------------------------------+
| Variable_name | Value                                             |
+---------------+---------------------------------------------------+
| datadir       | ...\mysql\data\ |
+---------------+---------------------------------------------------+
1 row in set

在datadir目录下，每个数据库对应一个目录，当我们建一个shendb的数据库时，此目录下就会有一个shendb的文件夹。
在该数据库下分别以shen_存储引擎格式分别创建InnoDB、MyISAM、CSV、Memory、Archive五种存储引擎格式的表，其存储结构如下：

MyISAM类型的表会有三个文件(frm、MYD、MYI)，InnoDB类型的表会有两个文件(frm、ibd)。
这些文件中，frm类型的文件是所有存储类型的表都会生成的。因为.frm是MySQL里面表结构定义的文件。
我们主要看一下InnoDB和MyISAM里其它文件是怎么实现MySQL不同的存储引擎的索引的.

a. MyISAM

在 MyISAM 里面，另外有两个文件：
一个是.MYD 文件，D 代表 Data，是 MyISAM 的数据文件，存放数据记录，比如我们的 shen_myisam 表的所有的表数据。
一个是.MYI 文件，I 代表 Index，是 MyISAM 的索引文件，存放索引，比如我们在 id 字段上面创建了一个主键索引，那么主键索引就是在这个索引文件里面。
也就是说，在 MyISAM 里面，索引和数据是两个独立的文件。
那我们怎么根据索引找到数据呢？
MyISAM 的 B+Tree 里面，叶子节点存储的是数据文件对应的磁盘地址。所以从索引文件.MYI 中找到键值后，会到数据文件.MYD 中获取相应的数据记录。

这里是主键索引，如果是辅助索引，有什么不一样呢？
在 MyISAM 里面，辅助索引也在这个.MYI 文件里面。
辅助索引跟主键索引存储和检索数据的方式是没有任何区别的，一样是在索引文件里面找到磁盘地址，然后到数据文件里面获取数据。

b. InnoDB

InnoDB 只有一个文件（.ibd 文件），那索引放在哪里呢？
在 InnoDB 里面，它是以主键为索引来组织数据的存储的，所以索引文件和数据文件是同一个文件，都在.ibd 文件里面。
在 InnoDB 的主键索引的叶子节点上，它直接存储了我们的数据。

什么叫做聚集索引（聚簇索引）？
就是索引键值的逻辑顺序跟表数据行的物理存储顺序是一致的。（比如字典的目录是按拼音排序的，内容也是按拼音排序的，按拼音排序的这种目录就叫聚集索引）。
在 InnoDB 里面，它组织数据的方式叫做（聚集）索引组织表（clusterd indexorganize table），所以主键索引是聚集索引，非主键都是非聚集索引。
如果 InnoDB 里面主键是这样存储的，那主键之外的索引，比如我们在 name 字段上面建的普通索引，又是怎么存储和检索数据的呢？

InnoDB 中，主键索引和辅助索引是有一个主次之分的。
辅助索引存储的是辅助索引和主键值。如果使用辅助索引查询，会根据主键值在主键索引中查询，最终取得数据。
比如我们用 name 索引查询 name= 'Qingshan'，它会在叶子节点找到主键值，也就是 id=1，然后再到主键索引的叶子节点拿到数据。

为什么在辅助索引里面存储的是主键值而不是主键的磁盘地址呢？如果主键的数据类型比较大，是不是比存地址更消耗空间呢？
我们前面说到 B Tree 是怎么实现一个节点存储多个关键字，还保持平衡的呢？
是因为有分叉和合并的操作，这个时候键值的地址会发生变化，所以在辅助索引里面不能存储地址。

另一个问题，如果一张表没有主键怎么办？
1、如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。
2、如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引。
3、如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。在表里查找这个隐藏列的话，使用_rowid。

select A._rowid, A.* from blog A;

四、索引使用原则

1. 列的离散(sàn)度

离散度公式：`count(distinct(column_name)) : count(*)`，列的全部不同值和所有数据行的比例。数据行相同的情况下，分子越大，列的离散度就越高。

了解了离散度公式后，我们再来思考一个问题：在name上面建立索引和在性别gender上建立索引有什么区别？

-- 建表，插入60条数据
CREATE TABLE `user_innodb` (
  `id` int(11) PRIMARY KEY AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `gender` tinyint(1) DEFAULT NULL,
  `phone` varchar(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

我们可以分别在name和gender上建立索引，然后查看一下在根据name、gender查找时的执行计划。

-- name字段创建索引
ALTER TABLE user_innodb DROP INDEX idx_user_name;
ALTER TABLE user_innodb ADD INDEX idx_user_name (name);
-- gender字段创建索引
ALTER TABLE user_innodb DROP INDEX idx_user_gender;
ALTER TABLE user_innodb ADD INDEX idx_user_gender

根据gender查询的执行计划：可以看到查询到了49行；

mysql> explain select * from user_innodb where gender=0;
+----+-------------+-------------+------+---------------+------------+---------+-------+------+-------+
| id | select_type | table       | type | possible_keys | key        | key_len | ref   | rows | Extra |
+----+-------------+-------------+------+---------------+------------+---------+-------+------+-------+
|  1 | SIMPLE      | user_innodb | ref  | idx_gender    | idx_gender | 2       | const |   49 | NULL  |
+----+-------------+-------------+------+---------------+------------+---------+-------+------+-------+

根据name查询的执行计划：可以看到只查询了1行；

mysql> explain select * from user_innodb where name = 'bigShen';
+----+-------------+-------------+------+---------------+----------+---------+-------+------+-------------+
| id | select_type | table       | type | possible_keys | key      | key_len | ref   | rows | Extra       |
+----+-------------+-------------+------+---------------+----------+---------+-------+------+-------------+
|  1 | SIMPLE      | user_innodb | ref  | idx_name      | idx_name | 767     | const |    1 | Using where |
+----+-------------+-------------+------+---------------+----------+---------+-------+------+-------------+

查看表上的索引：

mysql> show index from user_innodb;
+-------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table       | Non_unique | Key_name   | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| user_innodb |          0 | PRIMARY    |            1 | id          | A         |          60 | NULL     | NULL   |      | BTREE      |         |               |
| user_innodb |          1 | idx_gender |            1 | gender      | A         |           4 | NULL     | NULL   | YES  | BTREE      |         |               |
| user_innodb |          1 | idx_name   |            1 | name        | A         |          60 |      191 | NULL   | YES  | BTREE      |         |               |
+-------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

查看表上的索引列的Cardinality字段，代表基数，也就是预估的不重复的值的数量。索引的基数与表总行数越接近，列的离散度就越高。
如果我们在gender上创建字段，索引的B+Tree数据结构里面重复的值太多，MySQL优化器发现走索引和走全表扫描差不了多少，就算建了索引也不一定走索引。
也就是说：建立索引，要选择离散度高，重复概率越小的字段。

2.联合索引最左匹配原则

之前说到的是针对单列建立索引，但有时候我们是多个条件一起查询，就会用到联合索引。单列索引可以看做是特殊的联合索引。
比如为user表的name、phone同时建立索引。

ALTER TABLE user_innodb DROP INDEX idx_name;
ALTER TABLE user_innodb DROP INDEX idx_gender;
-- name和phone创建联合索引
ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);

联合索引在B+Tree中是复合的数据结构，它是按照从左到右的顺序来建立搜索树的(name在左，phone在右)。
从图中可以看出，name是有序的，phone是无序的；只有在name相同时，phone才是有序的。
这个时候我们根据name='bigShen' and phone='186xxx'去查询数据时，B+Tree会先比较name来确定下一步的搜索方法，是往左还是往右。如果name相同再比较phone。但是如果查询条件中没有name，就不知道第一步要查哪个节点，因为建立搜索树的时候name是第一个比较因子，所以用不到索引。

a. 什么时候用到联合索引

下面的3条查询语句，哪个能用到索引呢？

 select * from user_innodb where name = 'bigShen' and phone='18616351101';
 select * from user_innodb where name = 'bigShen';
 select * from user_innodb where phone = '18616351101';

查看对应执行计划:

mysql> explain select * from user_innodb where name = 'bigShen' and phone='18616351101';
+----+-------------+-------------+------+-------------------+-------------------+---------+-------------+------+------------------------------------+
| id | select_type | table       | type | possible_keys     | key               | key_len | ref         | rows | Extra                              |
+----+-------------+-------------+------+-------------------+-------------------+---------+-------------+------+------------------------------------+
|  1 | SIMPLE      | user_innodb | ref  | comidx_name_phone | comidx_name_phone | 814     | const,const |    1 | Using index condition; Using where |
+----+-------------+-------------+------+-------------------+-------------------+---------+-------------+------+------------------------------------+
1 row in set

根据name和phone来查询时，可以用到联合索引

mysql> explain select * from user_innodb where name = 'bigShen';
+----+-------------+-------------+------+-------------------+-------------------+---------+-------+------+-------------+
| id | select_type | table       | type | possible_keys     | key               | key_len | ref   | rows | Extra       |
+----+-------------+-------------+------+-------------------+-------------------+---------+-------+------+-------------+
|  1 | SIMPLE      | user_innodb | ref  | comidx_name_phone | comidx_name_phone | 767     | const |    1 | Using where |
+----+-------------+-------------+------+-------------------+-------------------+---------+-------+------+-------------+
1 row in set

根据name来单独查询时，可以用到联合索引。

mysql> explain select * from user_innodb where phone = '18616351101';
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table       | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | user_innodb | ALL  | NULL          | NULL | NULL    | NULL |   60 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+

根据phone来单独查询时，type=ALL，无法使用联合索引，走的全表扫描。

所以，我们在建立联合索引时，一定要把最常用的列放在最左边。

b. 如何创建联合索引

某一天，我们的DBA找到我们，说我们的项目里有两个sql查询很慢：

SELECT * FROM user_innodb WHERE name= ? AND phone = ?;
SELECT * FROM user_innodb WHERE name= ?;

按照我们的想法，一个查询创建一个索引，针对这两条SQL创建了两个索引，这种做法正确吗？

CREATE INDEX idx_name on user_innodb(name);
CREATE INDEX idx_name_phone on user_innodb(name,phone);

当我们创建一个联合索引时，按照最左匹配原则，用左边的name字段去查询的时候，也能用到索引，所以第一个索引根本是没必要创建的。
当我们创建联合索引时，比如 index(a,b,c)，其实相当于同时创建了index(a)、index(a,b)、index(a,b,c)三种索引。
用 where b=? 或者 where c=? 或者 where b=? and c=? 或者 where a=? and c=?都不能用到索引。不能不用第一个字段，不能中断。

3.覆盖索引，避免回表

回表：非主键索引，我们先通过索引找到主键索引的键值，在通过主键值查出索引里没有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程叫做回表。
例如：select * from user_innodb where name='青山';

覆盖索引：在索引里面，不管是单列索引还是联合索引，如果select的数据列只用从索引中就能取得，不必从数据区读取，这时候使用的索引就叫做覆盖索引，这样就避免了回表。

下面我们来演示一下使用覆盖索引：
首先，为user_innodb表创建联合索引：

ALTER TABLE user_innodb DROP INDEX comixd_name_phone;
ALTER TABLE user_innodb add INDEX `comixd_name_phone` (`name`,`phone`);

分别查看 select * 和 select name,phone 的执行计划：

EXPLAIN SELECT name,phone FROM user_innodb WHERE name= '青山' AND phone = '13666666666';
EXPLAIN SELECT name FROM user_innodb WHERE name= '青山' AND phone = '13666666666';
EXPLAIN SELECT phone FROM user_innodb WHERE name= '青山' AND phone = '13666666666';

mysql> explain select name,phone from user_innodb where name = 'bigShen' and phone='18616351101';
+----+-------------+-------------+------+-------------------+-------------------+---------+-------------+------+------------------------------------+
| id | select_type | table       | type | possible_keys     | key               | key_len | ref         | rows | Extra                              |
+----+-------------+-------------+------+-------------------+-------------------+---------+-------------+------+------------------------------------+
|  1 | SIMPLE      | user_innodb | ref  | comidx_name_phone | comidx_name_phone | 814     | const,const |    1 | Using index condition; Using where |
+----+-------------+-------------+------+-------------------+-------------------+---------+-------------+------+------------------------------------+

Extra里显示：Using index，即表示使用了覆盖索引，直接从索引总返回数据，没有回表。
最后，因为覆盖索引一些情况下可以避免回表，减少了磁盘IO次数，减少了数据的访问量，可以大大提升查询效率。这也是在写查询SQL时不推荐select *而是使用指定字段的原因。

查询索引列时，查询结果最好直接写明，不要用；因为InnoDB存储引擎的建立索引方式是：
聚集索引(主键索引)会关联数据对应磁盘地址，而非聚集索引是管理主键索引，
当查询结果在索引里可以直接匹配到时，可以直接从非聚集索引返回，如果用的话需要重新走一遍聚集索引，会增加磁盘IO，降低效率。

4. 索引条件下推(ICP) Index Condition Push Down

再来看这么一张表，在last_name 和first_name 上面创建联合索引。

drop table employees;
CREATE TABLE `employees` (
`emp_no` int(11) NOT NULL,
`birth_date` date NULL,
`first_name` varchar(14) NOT NULL,
`last_name` varchar(16) NOT NULL,
`gender` enum('M','F') NOT NULL,
`hire_date` date NULL,
PRIMARY KEY (`emp_no`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
alter table employees add index idx_lastname_firstname(last_name,first_name);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (1, NULL, '698', 'liu', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (2, NULL, 'd99', 'zheng', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (3, NULL, 'e08', 'huang', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (4, NULL, '59d', 'lu', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (5, NULL, '0dc', 'yu', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (6, NULL, '989', 'wang', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (7, NULL, 'e38', 'wang', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (8, NULL, '0zi', 'wang', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (9, NULL, 'dc9', 'xie', 'F', NULL);
INSERT INTO `employees` (`emp_no`, `birth_date`, `first_name`, `last_name`, `gender`, `hire_date`) VALUES (10, NULL, '5ba', 'zhou', 'F', NULL);

关闭ICP:默认ICP开启

查看参数：optimizer_switch的 index_condition_pushdown，为ICP属性
mysql> show variables like '%optimizer_switch%';
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name    | Value                                                                                                                                                                                                                                                                                                                                            |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| optimizer_switch | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set

现在我们要查询所有姓wang，并且名字最后一个字是zi 的员工，比如王胖子，王瘦子。查询的SQL：

select * from employees where last_name='wang' and first_name LIKE '%zi' ;

这条SQL 有两种执行方式：
1、根据联合索引查出所有姓wang 的二级索引数据，然后回表，到主键索引上查询全部符合条件的数据（3 条数据）。然后返回给Server 层，在Server 层过滤出名字以 zi 结尾的员工。
2、根据联合索引查出所有姓wang 的二级索引数据（3 个索引），然后从二级索引中筛选出first_name 以zi 结尾的索引（1 个索引），然后再回表，到主键索引上查询全部符合条件的数据（1 条数据），返回给Server 层。

很明显，第二种方式到主键索引上查找的数据更少。
注意，索引的比较是在存储引擎进行的，数据记录的比较，是在Server层进行的。而当first_name的条件不能用于索引过滤时，Server层不会把first_name的条件传递给存储引擎，所以读取了两条没有必要的记录。
这时候，如果满足last_name='wang'的记录有100000条，就会有99999条没有必要读取的记录。

分别演示关闭ICP和开启ICP的执行情况：
关闭ICP:

mysql> set optimizer_switch='index_condition_pushdown=off';  --关闭ICP
Query OK, 0 rows affected

mysql> show variables like '%optimizer_switch%';
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name    | Value                                                                                                                                                                                                                                                                                                                                             |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| optimizer_switch | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=off,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set

mysql> explain select * from employees where last_name='wang' and first_name LIKE '%zi';  -- 查找关闭ICP后执行计划
+----+-------------+-----------+------+------------------------+------------------------+---------+-------+------+-------------+
| id | select_type | table     | type | possible_keys          | key                    | key_len | ref   | rows | Extra       |
+----+-------------+-----------+------+------------------------+------------------------+---------+-------+------+-------------+
|  1 | SIMPLE      | employees | ref  | idx_lastname_firstname | idx_lastname_firstname | 18      | const |    3 | Using where |
+----+-------------+-----------+------+------------------------+------------------------+---------+-------+------+-------------+
1 row in set

从Extra中可以看到，只是Using Where。
Using Where 代表从存储引擎取回的数据不全部满足条件，需要在Server 层过滤。
先用last_name 条件进行索引范围扫描，读取数据表记录，然后进行比较，检查是否符合first_name LIKE '%zi' 的条件。此时3 条中只有1 条符合条件。

开启ICP:

mysql> set optimizer_switch='index_condition_pushdown=on';
Query OK, 0 rows affected

mysql> show variables like '%optimizer_switch%';
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name    | Value                                                                                                                                                                                                                                                                                                                                            |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| optimizer_switch | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set

mysql> explain select * from employees where last_name='wang' and first_name LIKE '%zi';
+----+-------------+-----------+------+------------------------+------------------------+---------+-------+------+-----------------------+
| id | select_type | table     | type | possible_keys          | key                    | key_len | ref   | rows | Extra                 |
+----+-------------+-----------+------+------------------------+------------------------+---------+-------+------+-----------------------+
|  1 | SIMPLE      | employees | ref  | idx_lastname_firstname | idx_lastname_firstname | 18      | const |    3 | Using index condition |
+----+-------------+-----------+------+------------------------+------------------------+---------+-------+------+-----------------------+
1 row in set

会发现Extra变为了Using index condition。
Using index condition表示执行了ICP索引下推。
把first_name LIKE '%zi'下推给存储引擎后，只会从数据表读取所需的1 条记录。

索引条件下推（Index Condition Pushdown），5.6 以后完善的功能。只适用于二级索引。ICP 的目标是减少访问表的完整行的读数量从而减少I/O 操作。

五、索引的创建与使用原则

因为索引对于改善查询性能的作用是巨大的，所以我们的目标是尽量使用索引。

1. 索引的创建

  1. 在用于where判断、order排序、join(on)字段上创建索引
  2. 索引的个数不要过多
    -- 浪费空间，更新变慢
  3. 区分度低的，比如性别，不要建索引
    -- 离散度太低，导致扫描行数太多，和全表扫描差不多
  4. 频繁更新的值，不要作为主键或索引
    -- 页分裂
  5. 复合索引把离散度高(区分度高)的写在前面
  6. 创建复合索引，而不是修改单列索引
  7. 过长的字段、怎么建立索引?
    -- 使用前缀索引。
    -- 当字段值比较长的时候，建立索引会消耗很多的空间，搜索起来会很慢。我们可以通过截取字段的前面一部分内容建立索引，这个就做前缀索引。
    问题是，截取多少呢？ 具体截取多少根据截取字段的列的离散度决定。
比如为地址address字段建立索引，address字段较长，截取一定的长度作为索引，当截取第9位时，发现列的离散度与0.83已经较为接近，则可以为address设置截取9位作为前置索引。
mysql> select 
count(distinct(address)) / count(1),
count(distinct left(address,5)) / count(1) as sub5,
count(distinct left(address,6)) / count(1) as sub6,
count(distinct left(address,7)) / count(1) as sub7,
count(distinct left(address,8)) / count(1) as sub8,
count(distinct left(address,9)) / count(1) as sub9
from person;
+-------------------------------------+--------+--------+--------+--------+--------+
| count(distinct(address)) / count(1) | sub5   | sub6   | sub7   | sub8   | sub9   |
+-------------------------------------+--------+--------+--------+--------+--------+
| 0.8333                              | 0.7000 | 0.7000 | 0.7333 | 0.7333 | 0.8000 |
+-------------------------------------+--------+--------+--------+--------+--------+
此时可以建立前置索引： alter table person add index idx_address(address(9));
  1. 为什么不建议用无序的值(如身份证、UUID)作为索引？
    -- 索引的数据结构，二叉树根据大小决定从左还是右查找下一节点，如果使用UUID等可能会在主键插入时引起B+Tree频繁的分裂和合并；建议用有序的或者自增的键作为索引。

2. 什么时候用不到索引

  1. 索引列上使用函数(replace、sub、sum)、表达式()、运算符(+-*/)时，不能使用索引
mysql> explain select * from shen_innodb where id+1=3;
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table       | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | ALL  | NULL          | NULL | NULL    | NULL |   60 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
1 row in set
  1. 字符串不加引号，出现隐式转换
mysql> explain select * from shen_innodb where phone = 18616351115;
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table       | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | ALL  | idx_phone     | NULL | NULL    | NULL |   60 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
1 row in set

mysql> explain select * from shen_innodb where phone = '18616351115';
+----+-------------+-------------+------+---------------+-----------+---------+-------+------+-----------------------+
| id | select_type | table       | type | possible_keys | key       | key_len | ref   | rows | Extra                 |
+----+-------------+-------------+------+---------------+-----------+---------+-------+------+-----------------------+
|  1 | SIMPLE      | shen_innodb | ref  | idx_phone     | idx_phone | 47      | const |    1 | Using index condition |
+----+-------------+-------------+------+---------------+-----------+---------+-------+------+-----------------------+
1 row in set

  1. like条件中前面带%
    where 条件中 like abc%、like %abc、like %abc%都用不到索引吗？
    过滤的开销太大，所以无法使用索引，这个时候可以用全文索引。

  2. 负向查询
    not like不能

mysql> explain SELECT * FROM shen_innodb WHERE name NOT LIKE 'big';
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table       | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | ALL  | NULL          | NULL | NULL    | NULL |   60 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
1 row in set

mysql> explain SELECT * FROM shen_innodb WHERE name LIKE 'big';
+----+-------------+-------------+-------+----------------+----------------+---------+------+------+-------------+
| id | select_type | table       | type  | possible_keys  | key            | key_len | ref  | rows | Extra       |
+----+-------------+-------------+-------+----------------+----------------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | range | idx_name_phone | idx_name_phone | 767     | NULL |    1 | Using where |
+----+-------------+-------------+-------+----------------+----------------+---------+------+------+-------------+
1 row in set

!= 、<> 和NOT IN 在某些情况下可以：

mysql> EXPLAIN SELECT * FROM shen_innodb WHERE id not in (1,2,3);
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table       | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | ALL  | PRIMARY       | NULL | NULL    | NULL |   60 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
1 row in set

mysql> EXPLAIN SELECT * FROM shen_innodb WHERE id in (1,2,3);
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table       | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | range | PRIMARY       | PRIMARY | 4       | NULL |    3 | Using where |
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
1 row in set


mysql> EXPLAIN SELECT * FROM shen_innodb WHERE id <> 2;
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table       | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | range | PRIMARY       | PRIMARY | 4       | NULL |   59 | Using where |
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
1 row in set

mysql> EXPLAIN SELECT * FROM shen_innodb WHERE id != 2;
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table       | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | shen_innodb | range | PRIMARY       | PRIMARY | 4       | NULL |   59 | Using where |
+----+-------------+-------------+-------+---------------+---------+---------+------+------+-------------+
1 row in set

注意一个SQL 语句是否使用索引，跟数据库版本、数据量、数据选择度都有关系

其实，用不用索引，最终都是优化器说了算。
优化器本身是基于开销(cost base optimizer)，它不是基于规则或者语义的，哪种开销小就用哪种。

  不要在频繁更新的列上建索引、不要更新主键(因为InnoDB中，索引使用的B+Tree的数据结构来加速定位到索引，进而定位到数据的磁盘地址；索引上字段值变化，会导致在树结构中的大小变化，很可能会导致树重新计算来再平衡)；

  在建立联合索引的时候，一定要把最常用的列放在最左边	

  聚集索引(也是主键索引)： 在InnoDB存储引擎中，有两种索引类型，主键索引也叫聚集索引，非主键索引都是非聚集索引(辅助索引)。 
    聚集索引以B+Tree的数据结构存储索引，并关联数据磁盘地址；  Node(key、disk location、pre node、next node)
    非聚集索引也以B+Tree的数据结构存储索引，关联的是主键值；  Node(index key、primary key、pre node、next node)
posted @ 2020-04-12 20:06  BigShen  阅读(710)  评论(0)    收藏  举报