MySQL 学习 --- 数据结构和索引

本文参考了多篇文章集成的笔记，希望各位学习之前可以阅读以下参考资料先

概述

文章分几个部分；第一部分介绍了B-Tree 和 B+Tree 这种数据结构作为索引；第二部分介绍索引的最左前缀原则和覆盖索引；第三部分讲了一下主键优化及 explain 的相关资料；主要是要结合实例去理解，不然也好难记忆这些概念。同时MySQL 官方的 DOC 真的是大大的良心，可以在实践使用过程中遇到问题，查询资料，了解概念过后，作为系统学习的第一手资料！

数据结构

我们知道MySQL InnoDB 引擎和MyISAM 引擎都是以 B+ Tree 作为底层数据结构的，这种数据结构的目的就是建立索引，使我们可以通过索引更快地找到数据。

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是数据结构。

上图是个索引的示例，左边是数据库中的表数据，而右边是一个二叉树，每个节点对应于一个行地址位置，我们要找左边表中的最后一行，我们先通过二叉树，由34开始找到 23 ，再由23找到 “0xD1”这个行地址，获取数据。当然实际中我们不是使用二叉树，而是使用B - Tree 或是 B + Tree。下面我们先来看一下是什么是 B- Tree 和B + Tree 。

B - Tree 和 B + Tree

08B2-4 深度统一.mp4_20190201_161101.020

扫描二维码关注公众号，回复： 5551445 查看本文章

可以看到上面是 B – Tree 的定义，或是这样描述

下面来具体介绍一下B-树（Balance Tree），一个m阶的B树具有如下几个特征：

根结点至少有两个子女。
每个中间节点都包含k-1个元素和k个孩子，其中 m/2 <= k <= m
每一个叶子节点都包含k-1个元素，其中 m/2 <= k <= m
所有的叶子结点都位于同一层。
每个节点中的元素从小到大排列，节点当中k-1个元素正好是k个孩子包含的元素的值域分划。

直观的例子就是如下：

我们再来看一下查找一个元素，逻辑过程应该是怎么样的？下面是查找算法的伪代码，出处

    BTree_Search(node, key) {
        if(node == null) return null;
        foreach(node.key)
        {
            if(node.key[i] == key) return node.data[i];
                if(node.key[i] > key) return BTree_Search(point[i]->node);
        }
        return BTree_Search(point[i+1]->node);
    }
    data = BTree_Search(root, my_key);

一个度为d的B-Tree，设其索引N个key，则其树高h的上限为logd((N+1)/2)，检索一个key，其查找节点个数的渐进复杂度为O(logdN)。从这点可以看出，B-Tree是一个非常有效率的索引数据结构。

关于其他关于 B-Tree 的操作，可以看这一篇文章。

B+Tree

B+Tree 树是 B –Tree 的变种，它的定义如下：

一个m阶的B+树具有如下几个特征：

有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。
所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。

记住三点 B+Tree 的特征有利于我们理解下面讲的内容。文字似乎很难理解，我们来看一下示例：

那么设计成这种数据结构有什么好处呢？

单一节点存储更多的元素，使得查询的IO次数更少。
所有查询都要查找到叶子节点，查询性能稳定。
所有叶子节点形成有序链表，便于范围查询。（例如上图要查找 3 到 8 之间的数据）

为什么使用B-Tree（B+Tree）

直接原因就是和计算机组成原理有关。下面是一段简洁的概括

一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。

这一篇文章，也给出了使用 B + Tree 的动机，主要是基于以下几个事实：

不同的存储设备读取速度差异过大
从磁盘中读写 1 B , 与读写 1 KB 几乎一样快
磁盘的预读

局部性原理与磁盘预读

下面分别是局部原理和磁盘预读的介绍。

       由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：

当一个数据被用到时，其附近的数据也通常会马上被使用。

       程序运行期间所需要的数据通常比较集中。

       预读的长度一般为页（page）的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为4k），主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。

B + Tree 索引的性能分析

以下分析来自： http://blog.codinglabs.org/articles/theory-of-mysql-index.html

根据B-Tree的定义，可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：

每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。B-Tree中一次检索最多需要h-1次I/O（根节点常驻内存），渐进复杂度为O(h)=O(logdN)。

一般实际应用中，出度d是非常大的数字，通常超过100，因此h非常小（通常不超过3）。综上所述，用B-Tree作为索引结构效率是非常高的。

而红黑树这种结构，h明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O(h)，效率明显比B-Tree差很多。上文还说过，B+Tree更适合外存索引，原因和内节点出度d有关。从上面分析可以看到，d越大索引的性能越好，而出度的上限取决于节点内key和data的大小：

floor表示向下取整。由于B+Tree内节点去掉了data域，因此可以拥有更大的出度，拥有更好的性能。

MySQL索引实现

MyISAM 索引实现

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

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

MyISAM 这种索引方式（data中放的是行地址引用，而不是真实数据）称为 “非聚集”

InnoDB 索引实现

InnoDB 也是使用 B+Tree 作为索引结构，最大的区别在于叶子结点的保存的完整的数据记录而不是地址引用，而 MyISAM 的做法是data 保存地址引用，地址和数据文件分开的方式。

InnoDB 这种索引的方式称之为聚集索引，因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。

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

例如数据库中表 Bob 一行对应的主键值为 15 。

最左前缀原则

最左前缀原则使用的场景是进行复合索引（存在两个或两个以上的构成的索引）查询的时候。

来看一下下面的例子：

CREATE TABLE `student` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `cid` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `name_cid_INX` (`name`,`cid`),
  KEY `name_INX` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8



//建索引
create INDEX name_cid_INX ON student(name,cid)；

create INDEX name_INX ON student(name);

再看一下三条语句

EXPLAIN  SELECT * FROM student WHERE    name='小红';

EXPLAIN  SELECT * FROM student WHERE   cid=1;

EXPLAIN SELECT * FROM student WHERE   cid=1 AND name='小红';

这三句会产生不同的效果。我们先来分析，type 为 ref 和 index 的区别

作者：沈杰
链接：https://www.zhihu.com/question/36996520/answer/93256153
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

index：这种类型表示是mysql会对整个该索引进行扫描。要想用到这种类型的索引，对这个索引并无特别要求，只要是索引，或者某个复合索引的一部分，mysql都可能会采用index类型的方式扫描。但是呢，缺点是效率不高，mysql会从索引中的第一个数据一个个的查找到最后一个数据，直到找到符合判断条件的某个索引。所以对于你的第一条语句：
EXPLAIN SELECT * FROM student WHERE   cid=1;
判断条件是cid=1,而cid是(name,cid)复合索引的一部分，没有问题，可以进行index类型的索引扫描方式。explain显示结果使用到了索引，是index类型的方式。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ref：这种类型表示mysql会根据特定的算法快速查找到某个符合条件的索引，而不是会对索引中每一个数据都进行一一的扫描判断，也就是所谓你平常理解的使用索引查询会更快的取出数据。而要想实现这种查找，索引却是有要求的，要实现这种能快速查找的算法，索引就要满足特定的数据结构。简单说，也就是索引字段的数据必须是有序的，才能实现这种类型的查找，才能利用到索引。

再来看一下复合索引的索引索引排序，以上面例子

可以看到 name 作为第一个索引，是按它先排序的，而cid 此时的索引排序并不能产生作用，那么为什么第三语句会用到 use index 呢？依然会使用到这个复合索引呢？不是说应该是最左前缀匹配原则吗？是的，但是MySQL 底层做了优化，使得先按照 name 索引后再找 cid .

另外一个例子

例子来自参考资料

索引也不是建的多就好，毕竟生成索引也需要消耗内存空间，参考资料就提到了一种不建议建立索引的情况：索引的选择性较低。所谓索引的选择性（Selectivity），是指不重复的索引值（也叫基数，Cardinality）与表记录数（#T）的比值：

Index Selectivity = Cardinality / #T

这一点很容易去理解，要是索引是重复的，那么要查询出数据，必定花费更多的时间，所以要是可能提高选择性，那么查询到速率一定更高。

假设存在一个表，存在 first name 和 second name 字段，它们的选择性如下：

    SELECT count(DISTINCT(first_name))/count(*) AS Selectivity FROM employees.employees;
    +-------------+
    | Selectivity |
    +-------------+
    |      0.0042 |
    +-------------+
    SELECT count(DISTINCT(concat(first_name, last_name)))/count(*) AS Selectivity FROM employees.employees;
    +-------------+
    | Selectivity |
    +-------------+
    |      0.9313 |
    +-------------+

<first_name>显然选择性太低，<first_name, last_name>选择性很好，但是first_name和last_name加起来长度为30，有没有兼顾长度和选择性的办法？可以考虑用first_name和last_name的前几个字符建立索引，例如<first_name, left(last_name, 3)>，看看其选择性：

SELECT count(DISTINCT(concat(first_name, left(last_name, 3))))/count(*) AS Selectivity FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.7879 |
+-------------+

选择性还不错，但离0.9313还是有点距离，那么把last_name前缀加到4：

SELECT count(DISTINCT(concat(first_name, left(last_name, 4))))/count(*) AS Selectivity FROM employees.employees;.+-------------+
| Selectivity |
+-------------+
|      0.9007 |
+-------------+

这时选择性已经很理想了，而这个索引的长度只有18，比<first_name, last_name>短了接近一半，我们把这个前缀索引建上：

ALTER TABLE employees.employees
ADD INDEX `first_name_last_name4` (first_name, last_name(4));

此时再执行一遍按名字查询，比较分析一下与建索引前的结果：

SHOW PROFILES;
+----------+------------+---------------------------------------------------------------------------------+
| Query_ID | Duration   | Query                                                                           |
+----------+------------+---------------------------------------------------------------------------------+
|       87 | 0.11941700 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
|       90 | 0.00092400 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
+----------+------------+---------------------------------------------------------------------------------+

性能的提升是显著的，查询速度提高了120多倍。

InnoDB的主键选择与插入优化

在使用InnoDB存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键。

我们前面说的数据结构是 B+Tree ，数据记录本身被存于主索引（一颗B+Tree）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）。如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如下图所示：

如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置：

总的来说就是自增键更加适应了 B+ Tree 这种结构，相对于随机插入，分页重组节点的概率更低，性能更加好。

覆盖索引

覆盖索引是select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖。索引的字段不只包含查询列，还包含查询条件、排序等。这篇文章遇到的case解决方法就是用到了覆盖索引。

CREATE TABLE `t_order` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `order_code` char(12) NOT NULL,
  `order_amount` decimal(12,2) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uni_order_code` (`order_code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 


//查询语句
select order_code, order_amount from t_order order by order_code limit 1000;

下面是 explain 后的参数：

可以看到 Extra : Using fileSort ，那为什么MySQL没有利用索引（uni_order_code）扫描完成查询呢？因为MySQL认为这个场景利用索引扫描并非最优的结果。下面来看一下两种方式扫描方式：

1. 全表扫描、文件排序：

虽然是全表扫描，但是扫描是顺序的（不管机械硬盘还是SSD顺序读写性能都是高的），并且数据量不是特别大，所以这部分消耗的时间应该不是特别大，主要的消耗应该是在排序上。

2. 利用索引扫描、利用索引顺序：

uni_order_code是二级索引，索引上保存了（order_code,id），每扫描一条索引需要根据索引上的id定位（随机IO）到数据行上读取order_amount，需要1000次随机IO才能完成查询，而机械硬盘随机IO的效率是极低的（机械硬盘每秒寻址几百次）。

根据我们自己的分析选择全表扫描相对更优。如果把limit 1000改成limit 10，则执行计划会完全不一样。既然我们已经知道是因为随机IO导致无法利用索引，那么有没有办法消除随机IO呢？

有，覆盖索引。

ALTER TABLE `t_order` 
ADD INDEX `idx_ordercode_orderamount` USING BTREE (`order_code` ASC, `order_amount` ASC);

补充

我们从上面性能优化上看，explain 更多时候给我们提供了很大的帮助，下面这两个链接可以进一步地了解关于 explain 的信息：

https://dev.mysql.com/doc/refman/5.7/en/explain-output.html （官方文档）
https://dev.mysql.com/doc/workbench/en/wb-tutorial-visual-explain-dbt3.html （官方文档）

总结

B+Tree 作为索引和计算甲组合原理相关，和减少 IO次数有关
复合索引需要注意的是最左前缀原则
某些情况下可以适用覆盖索引来优化 SQL
explain 是个好工具
参考资料的内容要好好看！

参考资料

http://blog.codinglabs.org/articles/theory-of-mysql-index.html （极力推荐一看！！）
https://zhuanlan.zhihu.com/p/40820574
https://www.zhihu.com/question/36996520/answer/93256153
https://my.oschina.net/loujinhe/blog/1528233
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html （官方文档）
https://dev.mysql.com/doc/workbench/en/wb-tutorial-visual-explain-dbt3.html （官方文档）