博客主页: 系列专栏: MySQL
一句短话: 难在坚持,贵在坚持,成在坚持!

文章目录

  • 一. 索引的介绍
    • 1. 什么是索引
    • 2. 索引的使用
  • 二. 索引背后的数据结构
    • 1. 考虑使用哈希表
    • 2. 二叉搜索树
    • 3. N叉搜索树(B树, B+树)
    • 4. 注意事项

一. 索引的介绍

1. 什么是索引

索引 (Index) 是帮助MYSQL高效获取数据的数据结构, 是一种特殊的文件, 包含着对数据表里所有记录的引用指针; 可以对表中的一列或多列创建索引, 并指定索引的类型, 各类索引有各自的数据结构实现.

索引 (index) 其实好比书的目录, 用于加快查找的效率.

索引的作用

  • 数据库中的表、数据、索引之间的关系,类似于书架上的图书、书籍内容和书籍目录的关系。
  • 索引所起的作用类似书籍目录,可用于快速定位、检索数据。
  • 索引对于提高数据库的性能有很大的帮助。

使用场景:
要考虑对数据库表的某列或某几列创建索引,需要考虑以下几点:

  • 数据量较大,且经常对这些列进行条件查询。
  • 该数据库表的插入操作,及对这些列的修改操作频率较低。
  • 索引会占用额外的磁盘空间。

满足以上条件时,考虑对表中的这些字段创建索引,以提高查询效率。

反之,如果非条件查询列,或经常做插入、修改操作,或磁盘空间不足时,不考虑创建索引。

使用索引会提高空间的开销, 构造索引需要额外的硬盘空间来保存; 索引在提高找效率的同时也加剧了增删改的开销, 此时的增删改, 需要调整已经创建好的索引目录.

2. 索引的使用

创建主键约束(primary key)、唯一约束(unique)、外键约束(foreign key)时,会自动创建对应列的索引。

索引相关的操作使用index关键字.

  • 创建索引

对于非主键、非唯一约束、非外键的字段,可以创建普通索引

语法:

create index 自定义索引名 on 表名(字段名);

示例: 创建班级表中, name字段的索引.

-- 创建学生表
mysql> create table student (->     id int primary key,->     name varchar(20)-> );
Query OK, 0 rows affected (0.03 sec)
-- 给name列添加索引
mysql> create index idx_student_name on student(name);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

注意:

  1. 索引最好是在表创建之初就完成全部创建.

如果是在一个表中已经有很多条记录的基础上来创建索引, 这个操作是非常危险的, 这个时间段内就会开销大量的磁盘IO, 数据库就无法被正常使用, 如果数据量很大的话, 这个时间段是很长的, 也就是说, 数据库可能在较长一段时间内无法正常使用.

  1. 索引的存在是为了提高查询的速度, 但索引一定要创建在合适的列上才有意义.

比如, 如果上面的student表中再添加一个字段性别(sex), 给这个字段添加索引并不能提高查找速度, 因为记录中sex字段的值会有大量的重复数据.

  • 查看索引

语法:

show index from 表名;

示例:查看学生表已有的索引

mysql> show index from student;
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table   | Non_unique | Key_name         | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| student |          0 | PRIMARY          |            1 | id          | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |
| student |          1 | idx_student_name |            1 | name        | A         |           0 |     NULL | NULL   | YES  | BTREE      |         |               |
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
2 rows in set (0.00 sec)
  • 删除索引

语法:

drop index 索引名 on 表名;

示例:删除班级表中name字段的索引

-- 删除索引
mysql> drop index idx_student_name on student;
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0
-- 查看剩下的索引
mysql> show index from student;
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table   | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| student |          0 | PRIMARY  |            1 | id          | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |
+---------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
1 row in set (0.00 sec)

注意:

同样的, 删除索引也可能会开销大量的磁盘IO, 也是比较危险的操作.

二. 索引背后的数据结构

1. 考虑使用哈希表

哈希表的查找效率为O(1)

考虑索引的底层实现是否可以使用哈希表,

哈希表查找数据的过程: 把key代入哈希函数, 计算得到下标, 再根据下标取到对应的链表, 再去遍历比较key是否相等.

上面的过程只能查一条记录, 而在数据库中很多情况下需要的是范围查询.

比如: 查找id<8并且>6的学生信息

select * from student where id < 8 and id > 6;

类似于这种简单或者更复杂的范围查询在哈希表中是无法实现的.

总结: 哈希表不适合做数据库的索引, 哈希表只能进行相等比较, 不能处理> >= < <= between and…这些范围查询.

2. 二叉搜索树

普通的二叉搜索树查找的时间复杂度, 一般情况下可以认为是O(logN), 考虑最坏的情况单枝树的情况下, 时间复杂度为O(N).

如果这个二叉搜索树比较平衡(AVL / 红黑树), 时间复杂可以达到O(logN).

二叉搜索树可以中序遍历(从起点到终点)进行范围查询, 但数据库索引并没有使用二叉搜索树来实现, 原因如下:
首先, 数据库中的比较是要读硬盘(磁盘IO)的, 读硬盘的次数太多会拖慢查找速度.

二叉(只有左右两个节点, 一个节点中放置一条记录)意味着当元素个数很多的时候, 树的高度就会比较高, 树的高度决定了了查询的时候元素比较的次数, 这样的话数据量大的时候查询还是会慢.

3. N叉搜索树(B树, B+树)

N叉搜索树: 每个节点上有多个值, 同时又有多个分支.

N叉搜索树中其中一种典型的实现就是B树.

使用B树实现索引有如下特点:

不再是二叉搜索,而是N叉搜索,树的高度会降低,查询快

  • 叶子节点,非叶子节点,都可以存储数据,且可以存储多个数据
  • 通过中序遍历,可以访问树上所有节点

如果B树被作为实现索引的数据结构被创造出来,是因为它能够完美的利用“局部性原理”,其设计逻辑是这样的:

  • 内存读写快,磁盘读写慢,而且慢很多
  • 磁盘预读:磁盘读写并不是按需读取,而是按页预读,一次会读一页的数据,每次加载一些看起来是冗余的数据,如果未来要读取的数据就在这一页中,可以避免未来的磁盘读写,提高效率(通常,一页数据是4K)
  • 局部性原理:软件设计要尽量遵循“数据读取集中”与“使用到一个数据,大概率会使用其附近的数据”,这样磁盘预读能充分提高磁盘IO效能

这里的B树一个节点中有多条记录, 相对于上面的二叉搜索树, 树的高度会降低很多, 读写硬盘的次数减少了, 但总体的比较次数相差不多(一个节点上可能需要多次比较).

而最适合做数据库索引的结构是B+树, B+树在B树的基础上进行了进一步的改进, B+树是为索引这个场景量身定做的数据结构.

  1. B+树也是一个N叉搜索树, 每个节点上可能包含N个key, N个key划分出N个区间; 最后一个key就相当于最大值了.
  2. 父元素的key会在子元素中重复出现, 这样的重复出现会让叶子节点包含了所有数据的全集, 非叶子节点的所有值都会在叶子节点中体现出来.
  3. 会把叶子节点, 用类似于链表的方式首尾巴相连.

使用B+树实现索引有如下特点:

  • 作为一个N叉搜索树, 层级(树的高度)小, 比较的时候, 硬盘IO的次数就少.
  • 叶子之间,增加了链表,获取所有节点,不再需要中序遍历,使用链表的next节点就可以快速访问到
  • 范围查找方面,当定位min与max之后,中间叶子节点,就是结果集,不用中序回溯(范围查询在SQL中用得很多,这是B+树比B树最大的优势)
  • 非叶子节点不再存储数据,数据只存储在同一层的叶子节点上,B+树从根到每一个节点的路径长度一样,也就是说, 不管查询的什么, 中间比较的次数都是差不多的, 查询操作比较均衡, 而B树不是这样
  • 叶子节点存储实际记录行,记录行相对比较紧密的存储,适合大数据量磁盘存储;非叶子节点存储记录的id,不存储实际记录,这就意味着非叶子节点占用的空间是大大降低的,适合用内存存储, 更进一步降低了硬盘IO.

4. 注意事项

使用索引提高查询速度, 本质上是在减少硬盘IO的次数

MySQL中对于带有主键的表, 就是按照主键索引的B+树来组织的.

如果表中不止以有主键索引, 还有别的非主键列, 也有索引; 对于非主键列会构造另一个B+树, 树中非叶子节点存储的都是这一列里面的key(比如一堆学生的姓名), 到了叶子节点这一层, 存储的不是完整的数据行, 存的只是id(主键列);

所以, 当使用非主键列的索引进行查询时, 需要先查一遍索引列的B+树, 找到对应的主键列, 再查一遍主键列的B+树(回表), 查询过到对应的记录.

上面所说的数据库索引的实现用的是B+树这个结构, 要注意这里只是针对MySQL的InnoDB(最主流使用的一种存储引擎)这个数据引擎里面所使用的数据结构, 不同的数据库, 不同的引擎, 里面的存储数据的结构还可能存在差异.

MySQL之索引及其背后的数据结构相关推荐

  1. 索引及其背后的数据结构(顺带介绍了一下子查询和合并查询)

    索引及其背后的数据结构(顺带介绍了一下子查询和合并查询) 子查询

  2. mysql默认索引add index_mysql 索引( mysql index )

    索引 mysql index 索引是一种数据结构,可以是B-tree, R-tree, 或者 hash 结构.其中R-tree 常用于查询比较接近的数据:B-trees适合用于查找某范围内的数据,可以 ...

  3. MySQL索引背后的数据结构及算法原理【转】

    http://blog.codinglabs.org/articles/theory-of-mysql-index.html MySQL索引背后的数据结构及算法原理[转] 摘要 本文以MySQL数据库 ...

  4. MySQL索引背后的数据结构及算法原理--转

    MySQL索引背后的数据结构及算法原理 作者 张洋 | 发布于 2011-10-18 MySQL 索引 B树 优化 原文地址:http://blog.codinglabs.org/articles/t ...

  5. mysql匹配数据结构_MySQL索引背后的数据结构及原理

    前两天经历了武汉一行腾讯面试,数据库索引是一个面试热点,在此搜集相关资料,以备学习之用. 下面是一位牛人写得关于数据库索引的精品之作,因为很好,不敢修饰,转载至此与博友共享. 本文以MySQL数据库为 ...

  6. mysql索引背后的数据结构及算法

    摘自:http://blog.jobbole.com/24006/ 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引 ...

  7. MySQL索引背后的数据结构及算法原理zz

    摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持 也各不相同,因此MySQL数据库支持多种索引类型,如B ...

  8. 【转载】MySQL索引背后的数据结构及算法原理

    本文转载自http://blog.jobbole.com/24006/ 摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储 ...

  9. MySQL索引背后的数据结构及算法原理----惊叹的深入

    原文出处: 张洋    摘要 本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题.特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库 ...

最新文章

  1. java解析kafkaavro_如何使用Spring Kafka读取合并模式注册的AVRO消息?
  2. Leetcode1963. 使字符串平衡的最小交换次数[C++题解]:贪心
  3. Java Web专题(一)
  4. 支付宝首页新增商家服务进度卡片 目前正在灰度测试中
  5. python学习[第十四篇] 文件的输入与输出
  6. 中兴助印尼Smartfren测试大规模MIMO技术
  7. android simpliadapter的两种用法
  8. mame新版ROM下载网站推荐
  9. python小学教材全解_小学教材全解三年级下数学
  10. arch模型 python_【一点资讯】Python玩转金融时间序列之ARCH与GARCH模型 www.yidianzixun.com...
  11. 【ArcGIS风暴】气象台站气温(降水)矢量数据插值成栅格气温(降水)空间数据
  12. Qt 控件添加右键菜单
  13. 计算机网络安全基础知识复习
  14. 暮光之城电影自制礼物大事记
  15. Windows AMD 安装 PyTorch
  16. html调用rpst 源码_在web页面中播放rtsp直播数据流方法
  17. winhex中判断+MBR+DBR+EBR方法
  18. java基于ssm开发的弹幕视频网站源码
  19. VBS脚本病毒总结与分析
  20. Qcon演讲实录 | XQUIC与多路径传输技术Multipath QUIC

热门文章

  1. java的HMACSHA1加密算法
  2. 西门子300 PLC 功能块及背景数据块的说明
  3. iceberg-flink 十:flink 窗口,事件时间,处理时间。
  4. 服务器虚拟cd,如何在VMware虚拟机上安装CD或DVD数据?
  5. 【歪门邪道】Android中如何快速回到主页
  6. AFM测试图像假象及其应对
  7. 大聪明教你学Java | 调用腾讯云短信接口,实现短信通知
  8. windows10家庭版修改中文用户名完美解决
  9. 世界主要港口中英文对照表
  10. 高通骁龙875夺安卓处理器桂冠,但外挂5G基带成为它的弊病