【深入理解MySQL的索引数据结构】

文章目录

📕索引底层数据结构与算法

📙索引数据结构

📘二叉树

二叉树数据结构

📘红黑树

红黑树的数据结构

📘Hash
  • 对索引的key进行一次hash计算就可以定位出数据存储的位置,很多时候Hash索引要比B+Tree索引更高效
  • 仅能满足 "=","IN",不支持范围查询,hash冲突问题。
📘B-Tree
  • 索引元素不重复
  • 从左到右递增排列。
📘B+Tree
  • 非叶子节点不存储data,只存储索引(冗余),可以放更多的索引
  • 叶子节点包含所有索引字段
  • 叶子节点用指针连接,提高区间访问的性能
  • 可以支持范围查询,有双向指针,假如查询Col1>30通过双向指针直接可以查询出来大于30的数据,而不是像B-Tree一样需要重新从根节点查询。

📙表在不同存储引擎的存储结构

📘MyISAM存储引擎索引实现
📚文件结构
  • .frm结尾的文件:表结构文件
  • .MYD结尾的文件:数据文件
  • .MYI结尾的文件:索引文件
📚非聚集索引

假设查询Col1=30,这个时候会先去.MYI结尾的索引文件找到磁盘地址0XF3,然后再去.MYD结尾的数据文件获取这一行数据。索引和数据分开存储就叫做非聚集索引。

📘InnoDB存储引擎索引实现
📚文件结构
  • .frm结尾的文件:表结构文件
  • .ibd结尾的文件:数据和索引文件,按照B+Tree组织的一个索引结构文件
📚聚集索引

叶节点包含整行记录,例如Col1=30会把其他行(Col2、Col3)的数据放到一起,这就是聚集索引。从结构上来说,聚集索引直接就获取到了整行数据性能比非聚集索引效率更高。

📙为什么DBA总推荐使用整型自增主键做索引

前面提到 InnoDB存储引擎中.ibd文件必须要用B+Tree来组织索引结构。

  • 如果表里面有主键,那么就可以直接使用主键作为B+Tree来组织索引结构。
  • 如果表里面没有创建主键,它会从表中选择一列所以数据不重复的列作为主键。
  • 如果没有选到不重复的列,这个时候MySQL才会自增隐藏列作为主键。
  • 通常情况都会自己选择一列作为主键,而不是交由MySQL自增隐藏列,减少MySQL的工作。

选择整型效率更快。

  • 如果以字符串作为主键,那么要逐个字符对比ASCII码,这种工作模式在对比过程中,如果二个对比结果前面相同,就最后一个字符不相同,浪费的性能还是很高的。
  • 整型存储的空间更小,会节约硬件资源。

假设我先插入8后插入7,即非自增插入数据,这个B+Tree结果是如何变化的呢?
5/6/8这个大节点放满了,插入7
放不下了,进行拆分平衡

假设后面插入9/10这种自增的数据,B+Tree会直接往后面开一个节点,性能比对来说,肯定是自增的会高一些。

📙为什么非主键索引结构叶子节点存储的是主键值?

非主键索引结构叶子节点存储主键值的原因主要有两个:

  • 保持一致性:当数据库表进行DML(数据操纵语言,如INSERT、UPDATE、DELETE)操作时,同一行记录的页地址可能会发生改变。由于非主键索引保存的是主键的值,而非实际的数据记录,因此当数据记录发生移动或变更时,非主键索引无需进行更改,只需保持与主键值的对应关系即可,从而保持索引的一致性。
  • 节省存储空间:在InnoDB存储引擎中,数据本身已经按照主键索引的B+树结构进行存储。如果非主键索引也存储整行数据,那么每个非主键索引都会存储一份数据,这将导致大量的数据冗余和存储空间的浪费。而只存储主键值的方式可以极大地节省存储空间,因为主键索引已经包含了完整的数据记录。

非主键索引通过存储主键值,可以在查询时通过主键值快速定位到数据记录所在的位置,从而提高查询效率。

先用二级索引找到主键索引,然后使用主键索引回表去查询对应的数据。

📙MySQL最左前缀优化原则是怎么回事

  • 先对比name大小,比较字符大小,HanMeimei<Jeff
  • 然后对比age大小,比较年龄大小,30<31<32
  • 最后对比position大小,dev<manager
bash 复制代码
EXPLAIN SELECT * FROM employees WHERE name = 'Bill' and age = 31;
EXPLAIN SELECT * FROM employees WHERE age = 30 AND position = 'dev';
EXPLAIN SELECT * FROM employees WHERE position = 'manager';|

根据上述的联合索引,分析上述SQL,只有第一条SQL会走索引。

  • 联合索引遵循最左前缀原则,先使用name进行查找,这是name已经排好序了,直接可以查询。
  • 然后使用age去查找,发现30,31,32,28,22,30,30,这个是没有排序的,就走全表扫描了。
  • 后面就不会使用position继续查找了。
相关推荐
Yz987626 分钟前
hive的存储格式
大数据·数据库·数据仓库·hive·hadoop·数据库开发
武子康32 分钟前
大数据-231 离线数仓 - DWS 层、ADS 层的创建 Hive 执行脚本
java·大数据·数据仓库·hive·hadoop·mysql
黑色叉腰丶大魔王37 分钟前
《MySQL 数据库备份与恢复》
mysql
苏-言38 分钟前
Spring IOC实战指南:从零到一的构建过程
java·数据库·spring
Ljw...44 分钟前
索引(MySQL)
数据库·mysql·索引
菠萝咕噜肉i1 小时前
超详细:Redis分布式锁
数据库·redis·分布式·缓存·分布式锁
长风清留扬1 小时前
一篇文章了解何为 “大数据治理“ 理论与实践
大数据·数据库·面试·数据治理
OpsEye1 小时前
MySQL 8.0.40版本自动升级异常的预警提示
数据库·mysql·数据库升级
Ljw...1 小时前
表的增删改查(MySQL)
数据库·后端·mysql·表的增删查改
薯条不要番茄酱1 小时前
数据结构-8.Java. 七大排序算法(中篇)
java·开发语言·数据结构·后端·算法·排序算法·intellij-idea