Mysql索引底层数据结构

Mysql索引数据结构

当慢查询时，看SQL是否走索引。
索引的本质：索引是帮助Mysql高效获取数据的排好序的数据结构。
MySQL若不建立索引，查找某条数据时则会逐行扫描，每扫描一行数据就会做一次磁盘IO。
B-Tree:
叶节点具有相同的深度，叶节点的指针为空。
所有索引元素不重复。
叶节点中的数据索引从左到右递增排列。

B树模型图。在B树中，无论中间节点还是叶子节点都带有数据。

B+树模型图，只有叶子节点带有数据，其余中间节点仅仅是索引，没有任何数据关联。

B树与B+树的性能比较

查询过程看上去跟B树差不多，但还是有两点不同的，首先，B+树中间节点没有数据，只存索引数据，所以同样大小的磁盘页可以容纳更多的节点元素，这就意味着，数据量相同的情况下B+树比B树更加的”矮胖“，相应会减小IO次数。其次，B+树的查询必须最终查找到叶子节点，而B树只要找到匹配元素即可，无论匹配元素处于中间节点还是叶子节点。

因此，B树的查找性能并不稳定，最好的情况是只查根节点即可，最坏的情况是要查到叶子节点，而B+树每一次查找都是稳定的。

B+树比B树的优势有三个：

1、单一节点存储更多的元素，使得查询的IO次数减少；

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

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

为什么Mysql索引要用B+树不是B树？

用B+树不用B树考虑的是IO对性能的影响，B树的每个节点都存储数据，而B+树只有叶子节点才存储数据，所以查找相同数据量的情况下，B树的高度更高，IO更频繁。数据库索引是存储在磁盘上的，当数据量大时，就不能把整个索引全部加载到内存了，只能逐一加载每一个磁盘页（对应索引树的节点）。其中在MySQL底层对B+树进行进一步优化：在叶子节点中是双向链表，且在链表的头结点和尾节点也是循环指向的。

提问：为何不采用hash方式？
等值查询时可以，但无法满足范围查找

MySQL的MyISAM、InnoDB引擎

存储引擎是修饰表的。（数据库文件是存储在磁盘的MySQL安装目录的data文件夹下）

myisam引擎（非聚集）的数据库表对应3个文件：
FRM:存储表的结构定义文件
MYD:存储表内的数据行（存储了表的真实数据）
MYI:存储了表内的索引字段（即那棵B+树）
B+树的叶节点的data区域内存储的是MYD表内数据的行地址（即指针）

InnoDB引擎（聚集）
数据库表对应2个文件：
FRM:存储表的结构定义文件
IBD:存储的是表的索引+数据（即myisam的MYD+MYI的合并）
B+树的叶节点的data区域内存储的是一整行数据

MySQL中普遍使用B+Tree做索引，但在实现上又根据聚簇索引和非聚簇索引而不同。

聚簇索引

所谓聚簇索引，就是指主索引文件和数据文件为同一份文件，聚簇索引主要用在Innodb存储引擎中。在该索引实现方式中B+Tree的叶子节点上的data就是数据本身，key为主键，如果是一般索引的话，data便会指向对应的主索引。
在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的B+Tree。做这个优化的目的是为了提高区间访问的性能，如果要查询key为从18到49的所有数据记录，当找到18后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。

非聚簇索

非聚簇索引就是指B+Tree的叶子节点上的data，并不是数据本身，而是数据存放的地址。主索引和辅助索引没啥区别，只是主索引中的key一定得是唯一的。主要用在MyISAM存储引擎中。

为何InnoDB表必须有主键，并且推荐使用整型自增主键？

采用整型是因为在主键比较时更容易，比uuid更快速，自增是因为当插入新节点时，自动在叶节点处往后补充即可，若不是自增，B+树为保证节点的大小顺序，可能会产生节点的分裂和平衡的调整，十分耗时。

InnoDB的非主键索引
在叶节点处的data区域存储的并不是整条数据，而是整条数据的主键。（为保证数据的一致性和节省存储空间）

Mysql之联合索引

索引最左前缀原理
联合索引因为每个节点内存有多个字段，因此为保证数据从左到右依次递增，就将（假设）3个字段依次进行大小比较。

创作时间：2019年11月22日10:36:46 于公司