MySQL 索引 ：哈希索引、B+树索引、最左前缀匹配规则、全文索引
文章目录
- 索引
- 什么是索引
- 索引优缺点与适用场景
- 常见的索引
- 哈希索引
- 自适应哈希索引
- B+树索引
- 聚集索引
- 非聚集索引
- 使用方法
- 联合索引
- 最左前缀匹配规则
- 覆盖索引
- 全文索引
- 使用方法
索引
什么是索引
在数据库中，表、数据、索引之间的关系就类似于书籍、书籍内容、书籍目录。
倘若不使用索引，则MySQL必须遍历整个表，直到找到数据，而表越大，查询的时间则越长，则数据库的效率也就越低。而索引就类似于书籍的目录，可以帮助我们快速的定位、检索到需要的数据行，对提高数据库的性能有着很大的帮助。
在MySQL中，索引是一种特殊的文件，其中包含着对数据表里所有记录的引用指针。各类索引有各自的数据结构实现。
索引优缺点与适用场景
优点
- 大大加快了数据检索的速度
- 所有的列类型都可以被索引，也就是可以给任意字段设置索引
缺点
- 索引需要占用物理空间，建立的索引越多则需要的空间越大
- 创建和维护索引需要耗费时间，并且时间随着数据量的增加而增加
- 当对表中的数据进行增加、删除、修改的时候，索引也要动态的维护，降低了数据的维护速度
考虑到它的优缺点，通常在满足以下两种条件的情况下才会为其建立索引
- 数据量较大，并且经常对这些列进行查询
- 该数据库表的插入操作，以及对这些列的修改操作频率较低
常见的索引
因为MySQL 中索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。由于 InnoDB 存储引擎在 MySQL 数据库中使用最为广泛，所以下面的讨论主要以InnoDB 为例。
在InnoDB存储引擎中，主要支持以下三种常见的索引， 下面一一对其进行介绍
- B+树索引
- 哈希索引
- 全文索引
哈希索引
高级数据结构与算法 | 哈希 ：哈希冲突、负载因子、哈希函数、哈希表、哈希桶
如果对于哈希不了解的可以查看我之前的一篇博客。
哈希索引的原理其实就是通过除留余数法将键值转换为哈希值，并将数据存储对应的槽中，如果出现了哈希冲突，则使用链地址法进行解决，将数据插入对应槽中的链表。
由于哈希是直接通过哈希值来将数据映射到对应位置，所以哈希索引对于等值查询的效率特别高，但是也正因为这个特性，使得哈希查找在面对范围查找的时候就毫无用武之地了。
自适应哈希索引
在InnoDB存储引擎会监控对表上各个索引页的查询，如果它观察到建立哈希索引可以带来速度提升，则会自行建立哈希索引，这也就是自适应哈希索引。即会自动根据访问频率和模式来为热点数据建立哈希索引。
由于哈希索引是数据库自身自动创建并使用的，人工无法对其进行干预
B+树索引
高级数据结构与算法 | B树、B+树、B*树
B+树这一数据结构在这里就也不详细讲了，如果不了解的可以查看我之前的一篇博客。
比起哈希索引，B+树索引的优势主要在于排序查找以及区间查找
在数据库中，B+树索引可以分为聚集索引（主键索引）和非聚集索引（辅助索引），它们之间的区别在于叶子节点中存放的是否是一整行的信息（即用户数据）
ps(叶子节点那一层存储的是页，而具体的某一个叶子节点才是存储行)
聚集索引
聚集索引其实就是索引和数据在同一个数据结构中
由于InnoDB存储引擎中表的数据按照主键顺序存放，所以聚集索引也就是按照每张表的主键来构造出一颗B+树。由于数据真正的排序方式只能有一种，所以在每张表中只能存在着一个聚集索引。
这颗B+树的非叶子节点存放的是数据的索引，而叶子节点存放的即为整张表的行记录数据，所以我们通常也将叶子节点称为数据页，并且每个叶子节点之间用双向链表进行连接。
聚集索引对于主键的排序查找和范围查找速度非常快，并且由于叶子节点就是数据，所以只需要查找一次就可以得到结果
非聚集索引
对于非聚集索引（辅助索引）来说，叶子节点并不包含行记录的全部数据，而是包含了主键的值
也就是说，我们需要在非聚集索引中查找到主键，再通过主键在聚集索引中查找到具体的值，也就是需要两次查找。
这就好比我们在查看书籍后面的专有名词索引一样，通过某个关键词查找到其在哪一个章节中，再通过目录来找到具体的章节位置。所以非聚集索引其实也就是一个二级索引
基于以上特性，由于辅助索引的存在并不会影响数据在聚集索引中的组织，因此每张表中可以有多个辅助索引
使用方法
创建主键约束（PRIMARY KEY）、唯一约束（UNIQUE）、外键约束（FOREIGN KEY）时，会自动创建对应列的索引。
查看索引
SHOW INDEX FROM 表名
创建
CREATE INDEX 索引名 ON 表名（字段名）
或者
ALTER TABLE 表名 ADD {KEY | INDEX} 索引名
删除
DROP INDEX 索引名 ON 表名
联合索引
联合索引即对表上的多个列进行索引，例如下图。
联合索引和普通的B+树不同的地方在于它具有多个键值，虽然键值有序，但是是按照从左往右的优先级以此对键值的大小进行排序，例如上图有两个键值，首先会先按照第一个键值的大小进行排序，当第一个键相同时，再按照第二个键的大小进行排序。
因为以上特性，联合索引具有最左前缀匹配规则，当不满足规则时则不会使用联合索引，而是进行全索引扫描。
最左前缀匹配规则
就以上述数据进行举例，此时以键值（a, b）构建联合索引
全值匹配查询
SELECT * FROM TABLE WHERE a = xxx AND b = xxx 、
SELECT * FROM TABLE WHERE a = xxx
SELECT * FROM TABLE WHERE b = xxx
对于以上几条查询语句来说，虽然看起来差不多，但是效率却大相径庭。
对于前两句来说，它们是可以使用联合索引的，因为无论是按照a作为条件，或者是a和b作为条件，都可以利用索引进行搜索，因为前面也说过了，联合索引的排序是按照从左往右优先的，所以当查找条件中包含a的时候则不会出现问题。
但对于b=xxx则无法适用以上性质，因为在联合索引中，后面的主键只有在前面的主键相同时才会具有有序性，而单独适用它的时候显然数据是无序的，所以这时只能进行行全索引扫描。
对于范围查找也是这么一个道理，假设此时联合索引的主键为（a, b, c)
SELECT * FROM TABLE WHERE a > 3 AND b > 3
SELECT * FROM TABLE WHERE a > 3 AND b > 3 AND c > 3
SELECT * FROM TABLE WHERE a > 3 AND c > 3
同样按照上面的规则，前两种查询都可以适用联合索引，因为其遵循了从左至右的匹配原则，而第三条因为跳过了b，此时的数据是无序的，无法适用索引。
覆盖索引
覆盖索引即从辅助索引中就可以得到查询的记录，而不需要查询聚集索引中的记录。使用覆盖索引的一个好处就是由于辅助索引中不包含整行的所有记录，所以它的大小要远远小于聚集索引，因此可以减少大量的I/O操作。
由于辅助索引中叶子节点存放的数据就是主键，所以当我们要查找主键，或者通过主键来统计数量的时候，就可以使用覆盖索引来完成。
全文索引
在之前版本中只有InnoDB并不支持全文检索，而在InnoDB1.2.x版本之后，InnoDB也加入了全文检索的功能
全文索引即根据部分段落、句、词从数据库中查询除全文的技术，即根据部分查询词获取对应的文档。
主要依据倒排索引这一数据结构来实现，这一数据结构通常也在搜索引擎中进行使用，在我的之前的一篇博客中也曾介绍过这一数据结构。
项目介绍：搜素引擎
这里就简要的介绍一下InnoDB中的倒排索引
其拥有两种表现形式
- inverted file index（倒排文件索引）
表现形式 {单词， 单词所在的文档ID） - full inverted index（全文倒排索引）
表现形式{单词， （单词所在文档ID，在具体文档的位置）
例如我们存在以下数据
并将其构建成inverted file index（倒排文件索引）的形式
此时我们就建立起了各个单词与其对应文档的一个映射关系。
接着建立full inverted index（全文倒排索引）
此时在之前的基础上，我们不仅确定了单词所在的文章，还确定了其所在文章中的对应位置，虽然比起inverted file index来说更加复杂，占据的空间也更多，但是却能更好的定位数据，并且扩充一些其它的搜索特性
使用方法
创建全文索引
CREATE FULLTEXT INDEX 索引名 ON 表名(字段名);
查找方法
MATCH(要匹配的列) AGAINST(要查找的内容)
1.自然语言查询（Natural Language）
自然语言查询即普通的包含关键词的搜索，例如
SELECT * FROM (表名) WHERE MATCH(匹配列) AGAINST(查询内容)
2.Boolean
这个模式允许使用IN BOOLEAN MODE修饰符来进行全文检索，当使用该修饰符时，查询字符串的前后字符都会有特殊含义。例如+和-分别代表了该单词必须出现或者一定没出现
这句查询即匹配包含查询词1并且不包含查询词2的结果
SELECT * FROM 表名
WHERE MATCH (要匹配的列) AGAINST ('+查询词1 -查询词2' IN BOOLEAN MODE);
该模式所有选项如下
全文查询的结果依据相关度进行降序排序，相关度计算依据如下
- 查询词是否在文档中出现过
- 查询词在文档中出现的次数
- 查询词在索引列中的数量
- 包含查询词的文档数
MySQL 索引 ：哈希索引、B+树索引、最左前缀匹配规则、全文索引相关推荐
- 从MySQL Bug#67718浅谈B+树索引的分裂优化
从MySQL Bug#67718浅谈B+树索引的分裂优化 1月 6th, 2013 发表评论 | Trackback 问题背景 今天,看到Twitter的DBA团队发布了其最新的MySQL分支:Cha ...
- mysql中组合索引创建的原则是什么意思_面试前必须要掌握的MySQL索引最左前缀匹配原则...
在面试中,经常会遇到这种问题,如果我们设置联合索引的顺序是(a, b, c), 那么如果我们在查询时的顺序却是(a, c, b) 会走索引吗?这个问题被问到的频率之高,令人乍舌,在这篇文章中,我们就深 ...
- 找到符合条件的索引_高频面试题：MySQL联合索引的最左前缀匹配原则
前言 之前在网上看到过很多关于mysql联合索引最左前缀匹配的文章,自以为就了解了其原理,最近面试时和面试官交流,发现遗漏了些东西,这里自己整理一下这方面的内容. 最左前缀匹配原则 在mysql建立联 ...
- MySQL实验: 实践索引对全列匹配、最左前缀匹配、范围查询等条件的影响以及了解脏读、幻读等...
索引实验 实验目的:了解索引对于全列匹配,最左前缀匹配.范围查询的影响.实验所用数据库见文章最底部连接. 实验软件版本:5.7.19-0ubuntu0.16.04.1-log (Ubuntu) 实验存 ...
- 原创：史上最全最通俗易懂的，索引最左前缀匹配原则（认真脸）
索引最左前缀匹配原则 对于最左前缀匹配原则居然没有百度百科,实在是让我感觉不可思议. 最左前缀匹配原则,用几句话来概述就是: 顾名思义,就是最左优先,在创建多列索引时,要根据业务需求,where子句中 ...
- oracle组合索引最左原则,索引的最左前缀匹配原则的误区与索引下推技术
最左前缀匹配原则是指where条件中在使用到 > < in between like等范围搜索的这个即以前的字段,如果可以与联合索引的前几个一一匹配,就可以使用这个索引. 但是实际操作中我 ...
- 联合索引的最左前缀匹配原则
目录 联合索引 最左前缀匹配原则 最左匹配原则的成因 联合索引 所谓的联合索引就是指,由两个或以上的字段共同构成一个索引. 本文测试用例的数据表结构如下,一张简简单单的学生信息表 tb_student ...
- mysql最左前缀概念_Mysql的最左前缀匹配原则(上)
最左前缀在mysql的官方文档中称之为leftmost prefix,该原则适用于多列索引,想仅仅用三言两语来说清楚什么是最左前缀匹配原则不太现实,但是如果使用官方文档的一个例子来说明该原则,或许会好 ...
- mysql索引如何分裂节点_从MySQL Bug#67718浅谈B+树索引的分裂优化（转）
原文链接:http://hedengcheng.com/?p=525 问题背景 今天,看到Twitter的DBA团队发布了其最新的MySQL分支:Changes in Twitter MySQL 5. ...
最新文章
- socket开发：一台服务器同一端口同时在多个网卡上开启listen的误区理解。
- 数组中两数相加等于特定值，以字符串的形式输出两数角标
- IIS服务器上增加mp4格式MIME 类型映射设置具体步骤
- 我用MRS-ClickHouse构建的用户画像系统，让老板拍手称赞
- java冒泡排序法对数组进行排序
- mac vscode debug安装调试moodle
- [网路]Pads 2007常见问题备份解答
- 这届618：商家全渠道作战，天猫仍是主场
- 光伏产品标准 - IEC 61215:2021版系列简介及标准下载
- 大数据破获网售假耐克案
- AppStore上线审核
- ASP.NET Core 项目文件夹解读新框架
- Ubuntu command 记录
- 无损音乐刻录成cd有意义吗_Mac装机必备之拯救歌荒，好用的五款Mac音乐播放器推荐！...
- OSX上pf的简单配置笔记
- 收到华为官网鸿蒙的消息,IT之家用户反馈现已收到华为鸿蒙 HarmonyOS 2.0 推送
- 【2020/07/16修订】概率论与数理统计（电子科技大学） 知识梳理 · 第一版（1到8章 · 度盘）
- mysql导入bak文件
- 由DIY想到的面向对象思想
- 杰理之MIC到usb【篇】