MySQL BTREE索引

个人能力有限，如有错误请指出，共同学习。

二叉树

B树

B+树

特点：

聚簇索引

二级索引

key数据存储量估算：

若每个页可以存1000个key，而且树的高度是4，那么

前提条件如下：

插入步骤

步骤一

因为索引中还没有数据，所以此时的B+树只有一个空的根结点，又由于一个页只能存3个key，首先将10，20，5插入进去（实际上此步发生了3次插入），然后在页面内做数据排序，最终结果如下图：

步骤二：

由于根页面已经写满，此时插入8，将发生分裂（根页面分裂），大致步骤如下：

注意：在分裂过程中，根结点始终是不会变的，不管变成多大的树，根结点的页面号始终如一。

步骤五：

插入数据40，发现比根结点23大，找到103号页面，发现已满，执行分裂，分裂同上面叶子结点的分裂步骤。分裂后如图所示：

步骤六：

继续插入下一个数据9，因为比20小，找到101号页面，发现已满，需要做叶子结点分裂，如下图：

传统B+树的数据删除，一般都会有一个所谓的填充因子，来控制页面数据的删除比例，如果数据量小于这个填充因子所表示的数据量，就会有节点合并，这与分裂是相对应的。

InnoDB的实现与传统B+树算法有不同之处，InnoDB在删除索引数据时，会先检查当前页剩余的记录数，如果只剩下一条记录，就会直接将这个页面从B+树中摘除，也只有这种情况，InnoDB才会回收一个页面，InnoDB的页面没有合并一说，但是对于根节点，即使索引数据全部删除，根节点页依然存在，只不过是以空页的形式存在。

下面举个例子描述索引删除过程，前提条件与前面插入记录时一致。

删除数据 50

删除过程全部结束，最终得到一个空的索引页。

《MySQL运维内参》

B+树动画演示： https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html

只有 MEMORY 存储引擎的表才可以选择使用 BTREE 索引或者 HASH 索引，像我们 常用的innodb只支持btree索引 。两种不同类型的索引各有其不同的适用范围。

Hash索引只能用于对等比较，例如=,<=>（相当于=） *** 作符。时间复杂度是O(1)，一次查找便能定位数据，不像BTree索引需要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以Hash在 单值查询 下检索效率远高于BTree索引。

但是，事实上我们更多情况是使用btree而不是hash

HASH 索引有一些重要的特征需要在使用的时候特别注意，如下所示。

下面我们可以进行验证：

创建一个city_memory表，其中 country_id字段上加了 HASH索引

插入数据

1、先开看这条等值条件sql

2、那么再来看 大于和小于条件sql

3、那么in这种范围条件呢？

in 条件对于hash来说是支持的，同样btree当然也支持。而且btree索引在使用in条件找数据时相对于hash性能更好，因为rows由4变为2（说明使用btree扫描2行即可找到）证明如下：

4、 BETWEEN .. AND .. 条件呢？

BETWEEN .. AND .. 条件在 不会用到hash索引！再来看看 btree的情况：

BETWEEN .. AND .. 条件能够使用到btree索引。

5、like 条件呢？

为了使用like条件，我们先将country_id类型改为 varchar

我们再来执行：

like条件会让hash索引失效。我们再来看btree下的like怎样：

好的，btree下也支持 like的不带开头%的访问查询

1、先来看hash索引支不支持排序

hash索引果然不能用在排序中，这多么致命呀！产生了 Using filesort文件内排序。性能上是个大坑。

2、同样，我们知道分组是要基于排序的。排序不使用索引，分组当然也不使用索引了。验证如下：

最终不仅没使用到索引，还产生了文件内排序和使用临时表。

当使用 MEMORY 引擎表的时候，如果是默认创建的 HASH索引，就要注意 SQL 语句的编写，确保可以使用上索引，如果索引字段需要 范围查询、排序、分组 就请使用btree索引；

了解mysql的索引类型的时候，我觉得按照以下4中方式划分逻辑是比较清晰的。

1.存储结构 2.物理存储 3.作用字段 4.功能

按照数据存储的结构可以分B树索引和hash索引。

又称为 BTREE 索引，目前大部分的索引都是采用 B-树索引来存储的。B-树索引是一个典型的数据结构。

基于这种树形数据结构，表中的每一行都会在索引上有一个对应值。因此，在表中进行数据查询时，可以根据索引值一步一步定位到数据所在的行。

查询必须从索引的最左边的列开始。

查询不能跳过某一索引列，必须按照从左到右的顺序进行匹配。

存储引擎不能使用索引中范围条件右边的列。

也称为散列索引或 HASH 索引。MySQL 目前仅有 MEMORY 存储引擎和 HEAP 存储引擎支持这类索引。

其中，MEMORY 存储引擎可以支持 B-树索引和 HASH 索引，且将 HASH 当成默认索引。

HASH 索引不是基于树形的数据结构查找数据，而是根据索引列对应的哈希值的方法获取表的记录行。

不能使用 HASH 索引排序。

HASH 索引只支持等值比较，如“=”“IN()”或“<=>”。

HASH 索引不支持键的部分匹配，因为在计算 HASH 值的时候是通过整个索引值来计算的。

聚集索引是按照所以把数据排好序了，所以一个表只能存在一个聚集索引，其它的都是非聚集索引。

因这个特性，聚集索引是查询数据范围的时候有很大的性能优势。

但是也需要注意的是如果频繁更新的列不适合设置为聚集索引，

原因很简单，每次更新都需要从新排序，频繁的更新给的压力也大。

如果不指定的话，默认主键为聚集索引。

一个表里除了一个聚集索引外其他的都是非聚集索引，虽然不能把数据按照索引排序，但是索引数据是可以排序的。

所以非聚集索引查询范围的时候是先找索引列的范围，再通过这个索引查询行的值。

单列索引即一个索引只包含单个列。

组合索引指在表的多个字段组合上创建的索引，只有在查询条件中使用了这些字段的左边字段时，索引才会被使用。使用组合索引时遵循最左前缀集合

Primary Key（聚集索引）：InnoDB存储引擎的表会存在主键（唯一非null），如果建表的时候没有指定主键，则会使用第一非空的唯一索引作为聚集索引，否则InnoDB会自动帮你创建一个不可见的、长度为6字节的row_id用来作为聚集索引。

Key（普通索引）：是MySQL中的基本索引类型，允许在定义索引的列中插入重复值和空值

Unique（唯一索引）：索引列的值必须唯一，但允许有空值。若是组合索引，则列值的组合必须唯一。

主键索引是一种特殊的唯一索引，不允许有空值。

既不是主键索引也不是唯一索引的一般索引。

FULLTEXT（全文索引）：全文索引类型为FULLTEXT，在定义索引的列上支持值的全文查找，允许在这些索引列中插入重复值和空值。

全文索引可以在CHAR、VARCHAR或者TEXT类型的列上创建。

空间索引主要用于地理空间数据类型 GEOMETRY。

下面是 mysql官网给出的几个存储引擎和索引之间的关系 。

欢迎大家的意见和交流

email: li_mingxie@163.com

---