MySQL索引 B+tree和hash

Posted 2020-11-04 apperception

mysql中的索引其主要内容包括Mysql常用的的索引类型（主键索引、唯一索引、普通索引和全文索引和组合索引）和两种常用的结构B-tree、哈希索引（自定义哈希索引和Innodb自适应哈希索引）

B-tree(MongoDB)

B-Tree就是我们常说的B树，B树这种数据结构常常用于实现数据库索引，因为它的查找效率比较高。

每次磁盘IO读取的数据我们称之为一页（page）。一页的大小与操作系统有关，一般为4k或者8k。这也就意味着读取一页内数据的时候，实际上发生了一次磁盘IO。

二叉查找树查询的时间复杂度是O（logN），查找速度最快和比较次数最少，既然性能已经如此优秀，但为什么实现索引是使用B-Tree而不是二叉查找树，关键因素是磁盘IO的次数。

数据库索引是存储在磁盘上，当表中的数据量比较大时，索引的大小也跟着增长，达到几个G甚至更多。当我们利用索引进行查询的时候，不可能把索引全部加载到内存中，只能逐一加载每个磁盘页，这里的磁盘页就对应索引树的节点。

从二叉树的查找过程了来看，树的高度和磁盘IO的次数都是4，所以最坏的情况下磁盘IO的次数由树的高度来决定。

从前面分析情况来看，减少磁盘IO的次数就必须要压缩树的高度，让瘦高的树尽量变成矮胖的树，所以B-Tree就在这样伟大的时代背景下诞生了。

 B+tree（MySQL）

与B树的查询过程没有什么区别。但实际上有两点不一样：

a、首先B+树的中间节点不存储卫星数据，所以同样大小的磁盘页可以容纳更多的节点元素，如此一来，相同数量的数据下，B+树就相对来说要更加矮胖些，磁盘IO的次数更少。

b、由于只有叶子节点才保存卫星数据，B+树每次查询都要到叶子节点；而B树每次查询则不一样，最好的情况是根节点，最坏的情况是叶子节点，没有B+树稳定。

单节点可以存储更多的元素，使得查询磁盘IO次数更少。

所有查询都要查找到叶子节点，查询性能稳定。

所有叶子节点形成有序链表，便于范围查询。

组合索引

alter table newcity   add index idx(CountryCode,District,Name);  

索引从最左开始组合的。所以依次生成了三个索引。

可用explain 查看执行计划