关于mysql:索引

1次阅读

共计 8637 个字符,预计需要花费 22 分钟才能阅读完成。

索引

一、什么是索引?

索引是一种非凡的文件(InnoDB 数据表上的索引是表空间的一个组成部分),它们蕴含着对数据表里所有记录的援用指针。

索引是一种数据结构。数据库索引,是数据库管理系统中一个排序的数据结构,以帮助疾速查问、更新数据库表中数据。索引的实现通常应用 B 树及其变种 B + 树。

更艰深的说,索引就相当于目录。为了不便查找书中的内容,通过对内容建设索引造成目录。索引是一个文件,它是要占据物理空间的。

二、索引有哪些优缺点?

1. 索引的长处

能够大大放慢数据的检索速度,这也是创立索引的最次要的起因。

通过应用索引,能够在查问的过程中,应用优化暗藏器,进步零碎的性能。

2. 索引的毛病

工夫方面:创立索引和保护索引要消耗工夫,具体地,当对表中的数据进行减少、删除和批改的时候,索引也要动静的保护,会升高增 / 改 / 删的执行效率;

空间方面:索引须要占物理空间。

三、索引应用场景(重点)

1.where

上图中,依据 id 查问记录,因为 id 字段仅建设了主键索引,因而此 SQL 执行可选的索引只有主键索引,如果有多个,最终会选一个较优的作为检索的根据。

— 减少一个没有建设索引的字段 altertableinnodb1addsexchar(1);– 按 sex 检索时可选的索引为 nullEXPLAINSELECT*frominnodb1wheresex=’ 男 ’;

能够尝试在一个字段未建设索引时,依据该字段查问的效率,而后对该字段建设索引(alter table 表名 add index(字段名)),同样的 SQL 执行的效率,你会发现查问效率会有显著的晋升(数据量越大越显著)。

2.order by

当咱们应用 order by 将查问后果依照某个字段排序时,如果该字段没有建设索引,那么执行打算会将查问出的所有数据应用内部排序(将数据从硬盘分批读取到内存应用外部排序,最初合并排序后果),这个操作是很影响性能的,因为须要将查问波及到的所有数据从磁盘中读到内存(如果单条数据过大或者数据量过多都会升高效率),更无论读到内存之后的排序了。

然而如果咱们对该字段建设索引 alter table 表名 add index(字段名),那么因为索引自身是有序的,因而间接依照索引的程序和映射关系逐条取出数据即可。而且如果分页的,那么只用取出索引表某个范畴内的索引对应的数据,而不必像上述那取出所有数据进行排序再返回某个范畴内的数据。(从磁盘取数据是最影响性能的)

3.join

对 join 语句匹配关系(on)波及的字段建设索引可能提高效率

4. 索引笼罩

如果要查问的字段都建设过索引,那么引擎会间接在索引表中查问而不会拜访原始数据(否则只有有一个字段没有建设索引就会做全表扫描),这叫索引笼罩。因而咱们须要尽可能的在 select 后只写必要的查问字段,以减少索引笼罩的几率。

这里值得注意的是不要想着为每个字段建设索引,因为优先应用索引的劣势就在于其体积小。

四、索引有哪几种类型?

1. 主键索引:数据列不容许反复,不容许为 NULL,一个表只能有一个主键。

2. 惟一索引: 数据列不容许反复,容许为 NULL 值,一个表容许多个列创立惟一索引。

能够通过 ALTER TABLE table_name ADD UNIQUE (column); 创立惟一索引

能够通过 ALTER TABLE table_name ADD UNIQUE (column1,column2); 创立惟一组合索引

3. 一般索引: 根本的索引类型,没有唯一性的限度,容许为 NULL 值。

能够通过 ALTER TABLE table_name ADD INDEX index_name (column); 创立一般索引

能够通过 ALTER TABLE table_name ADD INDEX index_name(column1, column2, column3); 创立组合索引

4. 全文索引: 是目前搜索引擎应用的一种关键技术。

能够通过 ALTER TABLE table_name ADD FULLTEXT (column); 创立全文索引

五、索引的数据结构(b 树,hash)

索引的数据结构和具体存储引擎的实现无关,在 MySQL 中应用较多的索引有 Hash 索引,B+ 树索引等,而咱们常常应用的 InnoDB 存储引擎的默认索引实现为:B+ 树索引。

对于哈希索引来说,底层的数据结构就是哈希表,因而在绝大多数需要为单条记录查问的时候,能够抉择哈希索引,查问性能最快;其余大部分场景,倡议抉择 BTree 索引。

1.B 树索引

mysql 通过存储引擎取数据,基本上 90% 的人用的就是 InnoDB 了,依照实现形式分,InnoDB 的索引类型目前只有两种:BTREE(B 树)索引和 HASH 索引。

B 树索引是 Mysql 数据库中应用最频繁的索引类型,根本所有存储引擎都反对 BTree 索引。通常咱们说的索引不出意外指的就是(B 树)索引(理论是用 B + 树实现的,因为在查看表索引时,mysql 一律打印 BTREE,所以简称为 B 树索引)

查问形式:

主键索引区:PI(关联保留的时数据的地址)按主键查问,

一般索引区:si(关联的 id 的地址, 而后再达到下面的地址)。所以按主键查问, 速度最快

B+tree 性质:

n 棵子 tree 的节点蕴含 n 个关键字,不用来保留数据而是保留数据的索引。

所有的叶子结点中蕴含了全副关键字的信息,及指向含这些关键字记录的指针,且叶子结点自身依关键字的大小自小而大程序链接。

所有的非终端结点能够看成是索引局部,结点中仅含其子树中的最大(或最小)关键字。

B+ 树中,数据对象的插入和删除仅在叶节点上进行。

B+ 树有 2 个头指针,一个是树的根节点,一个是最小关键码的叶节点。

2. 哈希索引

简要说下,相似于数据结构中简略实现的 HASH 表(散列表)一样,当咱们在 mysql 中用哈希索引时,次要就是通过 Hash 算法(常见的 Hash 算法有间接定址法、平方取中法、折叠法、除数取余法、随机数法),将数据库字段数据转换成定长的 Hash 值,与这条数据的行指针一并存入 Hash 表的对应地位;如果产生 Hash 碰撞(两个不同关键字的 Hash 值雷同),则在对应 Hash 键下以链表模式存储。当然这只是简略模仿图。

六、索引的基本原理

索引用来疾速地寻找那些具备特定值的记录。如果没有索引,一般来说执行查问时遍历整张表。索引的原理很简略,就是把无序的数据变成有序的查问。

把创立了索引的列的内容进行排序

对排序后果生成倒排表

在倒排表内容上拼上数据地址链

在查问的时候,先拿到倒排表内容,再取出数据地址链,从而拿到具体数据

七、索引算法有哪些?

索引算法有 BTree 算法和 Hash 算法

1.BTree 算法

BTree 是最罕用的 mysql 数据库索引算法,也是 mysql 默认的算法。因为它不仅能够被用在 =,>,>=,<,<= 和 between 这些比拟操作符上,而且还能够用于 like 操作符,只有它的查问条件是一个不以通配符结尾的常量,例如:

— 只有它的查问条件是一个不以通配符结尾的常量 selectfromuserwherenamelike’jack%’;– 如果一通配符结尾,或者没有应用常量,则不会应用索引,例如:selectfromuserwherenamelike’%jack’;

2.Hash 算法

Hash Hash 索引只能用于对等比拟,例如 =,<=>(相当于 =)操作符。因为是一次定位数据,不像 BTree 索引须要从根节点到枝节点,最初能力拜访到页节点这样屡次 IO 拜访,所以检索效率远高于 BTree 索引。

八、索引设计的准则?

1. 适宜索引的列是呈现在 where 子句中的列,或者连接子句中指定的列。

2. 基数较小的类,索引成果较差,没有必要在此列建设索引。

3. 应用短索引,如果对长字符串列进行索引,应该指定一个前缀长度,这样可能节俭大量索引空间。

4. 不要适度索引。索引须要额定的磁盘空间,并升高写操作的性能。在批改表内容的时候,索引会进行更新甚至重构,索引列越多,这个工夫就会越长。所以只放弃须要的索引有利于查问即可。

九、创立索引的准则(重中之重)

索引虽好,但也不是无限度的应用,最好合乎一下几个准则

最左前缀匹配准则,组合索引十分重要的准则,mysql 会始终向右匹配直到遇到范畴查问 (>、<、between、like) 就进行匹配,比方 a = 1 and b = 2 and c > 3 and d = 4 如果建设 (a,b,c,d) 程序的索引,d 是用不到索引的,如果建设 (a,b,d,c) 的索引则都能够用到,a,b,d 的程序能够任意调整。

较频繁作为查问条件的字段才去创立索引

更新频繁字段不适宜创立索引

若是不能无效辨别数据的列不适宜做索引列(如性别,男女未知,最多也就三种,区分度切实太低)

尽量的扩大索引,不要新建索引。比方表中曾经有 a 的索引,当初要加 (a,b) 的索引,那么只须要批改原来的索引即可。

定义有外键的数据列肯定要建设索引。

对于那些查问中很少波及的列,反复值比拟多的列不要建设索引。

对于定义为 text、image 和 bit 的数据类型的列不要建设索引。

十、创立索引的三种形式,删除索引

1. 第一种形式:在执行 CREATE TABLE 时创立索引

CREATETABLEuser_index2 (idINTauto_increment PRIMARYKEY,first_nameVARCHAR(16),last_nameVARCHAR(16),id_cardVARCHAR(18),informationtext,KEYname(first_name, last_name),FULLTEXTKEY(information),UNIQUEKEY(id_card));

2. 第二种形式:应用 ALTER TABLE 命令去减少索引

ALTERTABLEtable_nameADDINDEXindex_name (column_list);

ALTER TABLE 用来创立一般索引、UNIQUE 索引或 PRIMARY KEY 索引。

其中 table_name 是要减少索引的表名,column_list 指出对哪些列进行索引,多列时各列之间用逗号分隔。

索引名 index_name 可本人命名,缺省时,MySQL 将依据第一个索引列赋一个名称。另外,ALTER TABLE 容许在单个语句中更改多个表,因而能够在同时创立多个索引。

3. 第三种形式:应用 CREATE INDEX 命令创立

CREATEINDEXindex_nameONtable_name (column_list);

CREATE INDEX 可对表减少一般索引或 UNIQUE 索引。(然而,不能创立 PRIMARY KEY 索引)

4. 删除索引

依据索引名删除一般索引、惟一索引、全文索引:alter table 表名 drop KEY 索引名

altertableuser_indexdropKEYname;altertableuser_indexdropKEYid_card;altertableuser_indexdropKEYinformation;

删除主键索引:alter table 表名 drop primary key(因为主键只有一个)。这里值得注意的是,如果主键自增长,那么不能间接执行此操作(自增长依赖于主键索引):

须要勾销自增长再行删除:

altertableuser_index– 从新定义字段 MODIFYidint,dropPRIMARYKEY

但通常不会删除主键,因为设计主键肯定与业务逻辑无关。

十一、创立索引时须要留神什么?

非空字段:应该指定列为 NOT NULL,除非你想存储 NULL。在 mysql 中,含有空值的列很难进行查问优化,因为它们使得索引、索引的统计信息以及比拟运算更加简单。你应该用 0、一个非凡的值或者一个空串代替空值;

取值离散大的字段:(变量各个取值之间的差别水平)的列放到联结索引的后面,能够通过 count()函数查看字段的差别值,返回值越大阐明字段的惟一值越多字段的离散水平高;

索引字段越小越好:数据库的数据存储以页为单位一页存储的数据越多一次 IO 操作获取的数据越大效率越高。

十二、应用索引查问肯定能进步查问的性能吗?为什么?

通常,通过索引查问数据比全表扫描要快。然而咱们也必须留神到它的代价。

索引须要空间来存储,也须要定期维护,每当有记录在表中增减或索引列被批改时,索引自身也会被批改。这意味着每条记录的 INSERT,DELETE,UPDATE 将为此多付出 4,5 次的磁盘 I /O。因为索引须要额定的存储空间和解决,那些不必要的索引反而会使查问反应时间变慢。应用索引查问不肯定能进步查问性能,索引范畴查问 (INDEX RANGE SCAN) 实用于两种状况:

基于一个范畴的检索,个别查问返回后果集小于表中记录数的 30%

基于非唯一性索引的检索

十三、百万级别或以上的数据如何删除?

对于索引:因为索引须要额定的保护老本,因为索引文件是独自存在的文件, 所以当咱们对数据的减少, 批改, 删除, 都会产生额定的对索引文件的操作, 这些操作须要耗费额定的 IO, 会升高增 / 改 / 删的执行效率。

所以,在咱们删除数据库百万级别数据的时候,查问 MySQL 官网手册得悉删除数据的速度和创立的索引数量是成正比的。

所以咱们想要删除百万数据的时候能够先删除索引(此时大略耗时三分多钟)

而后删除其中无用数据(此过程须要不到两分钟)

删除实现后从新创立索引 (此时数据较少了) 创立索引也十分快,约十分钟左右。

与之前的间接删除相对是要疾速很多,更别说万一删除中断, 所有删除会回滚。那更是坑了。

十四、前缀索引

语法:index(field(10)),应用字段值的前 10 个字符建设索引,默认是应用字段的全部内容建设索引。

前提:前缀的标识度高。比方明码就适宜建设前缀索引,因为明码简直各不相同。

实操的难度:在于前缀截取的长度。

咱们能够利用 select count(*)/count(distinct left(password,prefixLen));,通过从调整 prefixLen 的值(从 1 自增)查看不同前缀长度的一个均匀匹配度,靠近 1 时就能够了(示意一个明码的前 prefixLen 个字符简直能确定惟一一条记录)

十五、什么是最左前缀准则?什么是最左匹配准则?

顾名思义,就是最左优先,在创立多列索引时,要依据业务需要,where 子句中应用最频繁的一列放在最右边。

最左前缀匹配准则,十分重要的准则,mysql 会始终向右匹配直到遇到范畴查问 (>、<、between、like) 就进行匹配,比方 a = 1 and b = 2 and c > 3 and d = 4 如果建设 (a,b,c,d) 程序的索引,d 是用不到索引的,如果建设 (a,b,d,c) 的索引则都能够用到,a,b,d 的程序能够任意调整。

= 和 in 能够乱序,比方 a = 1 and b = 2 and c = 3 建设 (a,b,c) 索引能够任意程序,mysql 的查问优化器会帮你优化成索引能够辨认的模式

十六、B 树和 B + 树的区别

在 B 树中,你能够将键和值寄存在外部节点和叶子节点;但在 B + 树中,外部节点都是键,没有值,叶子节点同时寄存键和值。

B+ 树的叶子节点有一条链相连,而 B 树的叶子节点各自独立。

1. 应用 B 树的益处

B 树能够在外部节点同时存储键和值,因而,把频繁拜访的数据放在凑近根节点的中央将会大大提高热点数据的查问效率。这种个性使得 B 树在特定数据反复屡次查问的场景中更加高效。

2. 应用 B + 树的益处

因为 B + 树的外部节点只寄存键,不寄存值,因而,一次读取,能够在内存页中获取更多的键,有利于更快地放大查找范畴。B+ 树的叶节点由一条链相连,因而,当须要进行一次全数据遍历的时候,B+ 树只须要应用 O(logN)工夫找到最小的一个节点,而后通过链进行 O(N)的程序遍历即可。而 B 树则须要对树的每一层进行遍历,这会须要更多的内存置换次数,因而也就须要破费更多的工夫

十七、Hash 索引和 B + 树所有有什么区别或者说优劣呢?

首先要晓得 Hash 索引和 B + 树索引的底层实现原理:

hash 索引底层就是 hash 表,进行查找时,调用一次 hash 函数就能够获取到相应的键值,之后进行回表查问取得理论数据。

B+ 树底层实现是多路均衡查找树。

对于每一次的查问都是从根节点登程,查找到叶子节点方能够取得所查键值,而后依据查问判断是否须要回表查问数据。

那么能够看出他们有以下的不同:

hash 索引进行等值查问更快(个别状况下),然而却无奈进行范畴查问。

因为在 hash 索引中通过 hash 函数建设索引之后,索引的程序与原程序无奈保持一致,不能反对范畴查问。

而 B + 树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也相似),人造反对范畴。

hash 索引不反对应用索引进行排序,原理同上。

hash 索引不反对含糊查问以及多列索引的最左前缀匹配。原理也是因为 hash 函数的不可预测。AAAA 和 AAAAB 的索引没有相关性。

hash 索引任何时候都防止不了回表查问数据,而 B + 树在合乎某些条件 (聚簇索引,笼罩索引等) 的时候能够只通过索引实现查问。

hash 索引尽管在等值查问上较快,然而不稳固。性能不可预测,当某个键值存在大量反复的时候,产生 hash 碰撞,此时效率可能极差。而 B + 树的查问效率比较稳定,对于所有的查问都是从根节点到叶子节点,且树的高度较低。

因而,在大多数状况下,间接抉择 B + 树索引能够取得稳固且较好的查问速度。而不须要应用 hash 索引。

十八、数据库为什么应用 B + 树而不是 B 树?

1.B 树只适宜随机检索,而 B + 树同时反对随机检索和程序检索;

2.B+ 树空间利用率更高,可缩小 I / O 次数,磁盘读写代价更低。

一般来说,索引自身也很大,不可能全副存储在内存中,因而索引往往以索引文件的模式存储的磁盘上。这样的话,索引查找过程中就要产生磁盘 I / O 耗费。

B+ 树的外部结点并没有指向关键字具体信息的指针,只是作为索引应用,其外部结点比 B 树小,盘块能包容的结点中关键字数量更多,一次性读入内存中能够查找的关键字也就越多,绝对的,IO 读写次数也就升高了。而 IO 读写次数是影响索引检索效率的最大因素;

3.B+ 树的查问效率更加稳固。

B 树搜寻有可能会在非叶子结点完结,越凑近根节点的记录查找时间越短,只有找到关键字即可确定记录的存在,其性能等价于在关键字选集内做一次二分查找。

而在 B + 树中,程序检索比拟显著,随机检索时,任何关键字的查找都必须走一条从根节点到叶节点的路,所有关键字的查找门路长度雷同,导致每一个关键字的查问效率相当。

B- 树在进步了磁盘 IO 性能的同时并没有解决元素遍历的效率低下的问题。

B+ 树的叶子节点应用指针程序连贯在一起,只有遍历叶子节点就能够实现整棵树的遍历。而且在数据库中基于范畴的查问是十分频繁的,而 B 树不反对这样的操作。

增删文件(节点)时,效率更高。因为 B + 树的叶子节点蕴含所有关键字,并以有序的链表构造存储,这样可很好进步增删效率。

4.B+ 树在满足聚簇索引和笼罩索引的时候不须要回表查问数据。

在 B + 树的索引中,叶子节点可能存储了以后的 key 值,也可能存储了以后的 key 值以及整行的数据,这就是聚簇索引和非聚簇索引。

在 InnoDB 中,只有主键索引是聚簇索引,如果没有主键,则筛选一个惟一键建设聚簇索引。如果没有惟一键,则隐式的生成一个键来建设聚簇索引。

当查问应用聚簇索引时,在对应的叶子节点,能够获取到整行数据,因而不必再次进行回表查问。

十九、什么是聚簇索引?何时应用聚簇索引与非聚簇索引

1. 什么是聚簇索引?

聚簇索引:将数据存储与索引放到了一块,找到索引也就找到了数据

非聚簇索引:将数据存储于索引离开构造,索引构造的叶子节点指向了数据的对应行,myisam 通过 key_buffer 把索引先缓存到内存中,当须要拜访数据时(通过索引拜访数据),在内存中间接搜寻索引,而后通过索引找到磁盘相应数据,这也就是为什么索引不在 key buffer 命中时,速度慢的起因

廓清一个概念:innodb 中,在聚簇索引之上创立的索引称之为辅助索引,辅助索引拜访数据总是须要二次查找,非聚簇索引都是辅助索引,像复合索引、前缀索引、惟一索引,辅助索引叶子节点存储的不再是行的物理地位,而是主键值

2. 何时应用聚簇索引与非聚簇索引?

3. 非聚簇索引肯定会回表查问吗?

不肯定,这波及到查问语句所要求的字段是否全副命中了索引,如果全副命中了索引,那么就不用再进行回表查问。

举个简略的例子,假如咱们在员工表的年龄上建设了索引,那么当进行 select age from employee where age < 20 的查问时,在索引的叶子节点上,曾经蕴含了 age 信息,不会再次进行回表查问。

二十、联结索引是什么?为什么须要留神联结索引中的程序?

MySQL 能够应用多个字段同时建设一个索引,叫做联结索引。在联结索引中,如果想要命中索引,须要依照建设索引时的字段程序挨个应用,否则无奈命中索引。

具体起因为:

MySQL 应用索引时须要索引有序,假如当初建设了 ”name,age,school” 的联结索引,那么索引的排序为: 先依照 name 排序,如果 name 雷同,则依照 age 排序,如果 age 的值也相等,则依照 school 进行排序。

当进行查问时,此时索引仅仅依照 name 严格有序,因而必须首先应用 name 字段进行等值查问,之后对于匹配到的列而言,其依照 age 字段严格有序,此时能够应用 age 字段用做索引查找,以此类推。

因而在建设联结索引的时候应该留神索引列的程序,个别状况下,将查问需要频繁或者字段选择性高的列放在后面。此外能够依据特例的查问或者表构造进行独自的调整。

正文完
 0