【深入理解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继续查找了。
相关推荐
OK_boom2 小时前
Dapper的数据库操作备忘
数据库
艺杯羹3 小时前
JDBC之ORM思想及SQL注入
数据库·sql·jdbc·orm·sql注入
blackA_3 小时前
数据库MySQL学习——day4(更多查询操作与更新数据)
数据库·学习·mysql
极限实验室4 小时前
Easysearch 迁移数据之 Reindex From Remote
数据库
朴拙数科4 小时前
基于LangChain与Neo4j构建企业关系图谱的金融风控实施方案,结合工商数据、供应链记录及舆情数据,实现隐性关联识别与动态风险评估
数据库·langchain·neo4j
小李学不完5 小时前
Oracle--SQL事务操作与管理流程
数据库
qq_441996055 小时前
为何 RAG 向量存储应优先考虑 PostgreSQL + pgvector 而非 MySQL?
数据库·mysql·postgresql
Ivan陈哈哈5 小时前
Redis是单线程的,如何提高多核CPU的利用率?
数据库·redis·缓存
wuqingshun3141595 小时前
蓝桥杯 5. 交换瓶子
数据结构·c++·算法·职场和发展·蓝桥杯
AI军哥5 小时前
MySQL8的安装方法
人工智能·mysql·yolo·机器学习·deepseek