MySQL【索引】

1、前言

索引是數據庫優化最經常使用也是最重要的手段之一, 經過索引一般能夠幫助用戶解決大多數的MySQL的性能優化問題。

2、索引概述

MySQL官方對索引的定義爲：索引（index）是幫助MySQL高效獲取數據的數據結構（有序）。

在數據以外，數據庫系統還維護者知足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據， 這樣就能夠在這些數據結構上實現高級查找算法，這種數據結構就是索引。

以下圖所示 :

左邊是數據表，一共有兩列七條記錄，最左邊的是數據記錄的物理地址（注意邏輯上相鄰的記錄在磁盤上也並非必定物理相鄰的）。爲了加快Col2的查找，能夠維護一個右邊所示的二叉查找樹，每一個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針，這樣就能夠運用二叉查找快速獲取到相應數據。

通常來講索引自己也很大，不可能所有存儲在內存中，所以索引每每以索引文件的形式存儲在磁盤上。

3、索引優點劣勢

優點

1） 相似於書籍的目錄索引，提升數據檢索的效率，下降數據庫的IO成本。

2） 經過索引列對數據進行排序，下降數據排序的成本，下降CPU的消耗。

劣勢

1） 實際上索引也是一張表，該表中保存了主鍵與索引字段，並指向實體類的記錄，因此索引列也是要佔用空間的。

2） 雖然索引大大提升了查詢效率，同時卻也下降更新表的速度，如對錶進行INSERT、UPDATE、DELETE。由於更新表時，MySQL 不只要保存數據，還要保存一下索引文件每次更新添加了索引列的字段，都會調整由於更新所帶來的鍵值變化後的索引信息。

4、索引結構

（一）存儲引擎對索引的支持

索引是在MySQL的存儲引擎層中實現的，而不是在服務器層實現的。因此每種存儲引擎的索引都不必定徹底相同，也不是全部的存儲引擎都支持全部的索引類型的。MySQL目前提供瞭如下4種索引：

1. BTREE 索引 ： 最多見的索引類型，大部分索引都支持 B 樹索引。

2. HASH 索引：只有Memory引擎支持 ， 使用場景簡單 。

3. R-tree 索引（空間索引）：空間索引是MyISAM引擎的一個特殊索引類型，主要用於地理空間數據類型，一般使用較少，不作特別介紹。

4. Full-text （全文索引） ：全文索引也是MyISAM的一個特殊索引類型，主要用於全文索引，InnoDB從Mysql5.6版本開始支持全文索引。

MyISAM、InnoDB、Memory三種存儲引擎對各類索引類型的支持

索引	InnoDB引擎	MyISAM引擎	Memory引擎
BTREE索引	支持	支持	支持
HASH 索引	不支持	不支持	支持
R-tree 索引	不支持	支持	不支持
Full-text	5.6版本以後支持	支持	不支持

咱們日常所說的索引，若是沒有特別指明，都是指B+樹（多路搜索樹，並不必定是二叉的）結構組織的索引。其中彙集索引、複合索引、前綴索引、惟一索引默認都是使用 B+tree 索引，統稱爲索引。

（二）BTREE 結構

BTree又叫多路平衡搜索樹，一顆m叉的BTree特性以下：

1. 樹中每一個節點最多包含m個孩子。

2. 除根節點與葉子節點外，每一個節點至少有[ceil(m/2)]個孩子。

3. 若根節點不是葉子節點，則至少有兩個孩子。

4 )全部的葉子節點都在同一層。

5. 每一個非葉子節點由n個key與n+1個指針組成，其中[ceil(m/2)-1] <= n <= m-1

以5叉BTree爲例，key的數量：公式推導[ceil(m/2)-1] <= n <= m-1。因此 2 <= n <=4 。

所以，當n>4時，中間節點分裂到父節點，兩邊節點分裂。

插入 C N G A H E K Q M F W L T Z D P R X Y S 數據爲例，演變過程以下：

1. 插入前4個字母 C N G A

2. 插入H，n>4，中間元素G字母向上分裂到新的節點

3. 插入E，K，Q不須要分裂

4. 插入M，中間元素M字母向上分裂到父節點G

5. 插入F，W，L，T不須要分裂

6. 插入Z，中間元素T向上分裂到父節點中

7. 插入D，中間元素D向上分裂到父節點中。而後插入P，R，X，Y不須要分裂

8. 最後插入S，NPQR節點n>5，中間節點Q向上分裂，但分裂後父節點DGMT的n>5，中間節點M向上分裂

到此，該BTREE樹就已經構建完成了， BTREE樹 和 二叉樹相比， 查詢數據的效率更高， 由於對於相同的數據量來講，BTREE的層級結構比二叉樹小，所以搜索速度快。

（三）B+TREE 結構

B+Tree爲BTree的變種，B+Tree與BTree的區別爲：

1. n叉B+Tree最多含有n個key，而BTree最多含有n-1個key。

2. B+Tree的葉子節點保存全部的key信息，依key大小順序排列。

3. 全部的非葉子節點均可以看做是key的索引部分。

因爲B+Tree只有葉子節點保存key信息，查詢任何key都要從root走到葉子，因此B+Tree的查詢效率更加穩定。

（四）MySQL中的B+Tree

MySQL 索引數據結構對經典的B+Tree進行了優化。

在原B+Tree的基礎上，增長一個指向相鄰葉子節點的鏈表指針，就造成了帶有順序指針的B+Tree，提升區間訪問的性能。

MySQL中的 B+Tree 索引結構示意圖:

5、索引種類

1）主鍵索引

數據列不容許重複，不容許爲NULL，一個表只能有一個主鍵索引。

2）惟一索引

數據列不容許重複，容許爲NULL值(可有多個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）組合索引

多列值組成一個索引，專門用於組合搜索，其效率大於索引合併。

ps：

索引合併，使用多個單列索引組合搜索
覆蓋索引，select的數據列只用從索引中就可以取得，沒必要讀取數據行，換句話說查詢列要被所建的索引覆蓋

5）全文索引

對文本的內容進行分詞，進行搜索，是目前搜索引擎使用的一種關鍵技術。

能夠經過ALTER TABLE table_name ADD FULLTEXT (column);建立全文索引

6、索引語法

索引在建立表的時候，能夠同時建立， 也能夠隨時增長新的索引。

準備環境:

create database demo_01 default charset=utf8mb4;

use demo_01;

CREATE TABLE `city` (
  `city_id` int(11) NOT NULL AUTO_INCREMENT,
  `city_name` varchar(50) NOT NULL,
  `country_id` int(11) NOT NULL,
  PRIMARY KEY (`city_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `country` (
  `country_id` int(11) NOT NULL AUTO_INCREMENT,
  `country_name` varchar(100) NOT NULL,
  PRIMARY KEY (`country_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


insert into `city` (`city_id`, `city_name`, `country_id`) values(1,'西安',1);
insert into `city` (`city_id`, `city_name`, `country_id`) values(2,'NewYork',2);
insert into `city` (`city_id`, `city_name`, `country_id`) values(3,'北京',1);
insert into `city` (`city_id`, `city_name`, `country_id`) values(4,'上海',1);

insert into `country` (`country_id`, `country_name`) values(1,'China');
insert into `country` (`country_id`, `country_name`) values(2,'America');
insert into `country` (`country_id`, `country_name`) values(3,'Japan');
insert into `country` (`country_id`, `country_name`) values(4,'UK');

（一）建立索引

語法 ：

CREATE 	[UNIQUE|FULLTEXT|SPATIAL]  INDEX index_name 
[USING  index_type]
ON tbl_name(index_col_name,...)

爲city表中的city_name字段建立索引 :

（二）查看索引

語法：

show index  from  table_name;

查看city表中的索引信息:

（三）刪除索引

語法 ：

DROP  INDEX  index_name  ON  tbl_name;

想要刪除city表上的索引idx_city_name，能夠操做以下：

（四）ALTER命令

1) alter  table  tb_name  add  primary  key(column_list); 
該語句添加一個主鍵，這意味着索引值必須是惟一的，且不能爲NULL
	
2) alter  table  tb_name  add  unique index_name(column_list);
這條語句建立索引的值必須是惟一的（除了NULL外，NULL可能會出現屢次）
	
3) alter  table  tb_name  add  index index_name(column_list);
添加普通索引， 索引值能夠出現屢次。
	
4) alter  table  tb_name  add  fulltext index_name(column_list);
該語句指定了索引爲FULLTEXT， 用於全文索引

7、索引設計原則

索引的設計能夠遵循一些已有的原則，建立索引的時候請儘可能考慮符合這些原則，便於提高索引的使用效率，更高效的使用索引。

1. 對查詢頻次較高，且數據量比較大的表創建索引。

2. 索引字段的選擇，最佳候選列應當從where子句的條件中提取，若是where子句中的組合比較多，那麼應當挑選最經常使用、過濾效果最好的列的組合。

3. 使用惟一索引，區分度越高，使用索引的效率越高。

4. 索引能夠有效的提高查詢數據的效率，但索引數量不是多多益善，索引越多，維護索引的代價天然也就水漲船高。

對於插入、更新、刪除等DML操做比較頻繁的表來講，索引過多，會引入至關高的維護代價，下降DML操做的效率，增長相應操做的時間消耗。另外索引過多的話，MySQL也會犯選擇困難病，雖然最終仍然會找到一個可用的索引，但無疑提升了選擇的代價。

5. 儘可能使用短索引，若是要建立索引的字段較長，能夠指定索引前綴。

索引建立以後也是使用硬盤來存儲的，假如構成索引的字段總長度比較短，那麼在給定大小的存儲塊內能夠存儲更多的索引值，相應的能夠有效的提高MySQL訪問索引的I/O效率。

6. 利用最左前綴，建立N個列組合而成的組合索引。

N個列的組合索引至關因而建立了N個索引，若是查詢時where子句中使用了組成該索引的前幾個字段，那麼這條查詢SQL能夠利用組合索引來提高查詢效率。

7. 儘可能的擴展索引，不要新建索引。好比表中已經有a的索引，如今要加(a,b)的索引，那麼只須要修改原來的索引便可。

或者說：儘可能使用組合索引。

建立組合索引:
	CREATE INDEX idx_name_email_status ON tb_seller(NAME,email,STATUS);

就至關於
	對name 建立索引 ;
	對name , email 建立了索引 ;
	對name , email, status 建立了索引 ;

8. 對於定義爲text、image和bit的數據類型的列不要創建索引。

9. 定義有外鍵的數據列必定要創建索引。

ps: MySQL支持外鍵的存儲引擎只有InnoDB ， 在建立外鍵的時候， 要求父表必須有對應的索引 ， 子表在建立外鍵的時候， 也會自動的建立對應的索引。

8、索引的使用

準備環境:

create table `tb_seller` (
	`sellerid` varchar (100),
	`name` varchar (100),
	`nickname` varchar (50),
	`password` varchar (60),
	`status` varchar (1),
	`address` varchar (100),
	`createtime` datetime,
    primary key(`sellerid`)
)engine=innodb default charset=utf8mb4; 

insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('alibaba','阿里巴巴','阿里小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('baidu','百度科技有限公司','百度小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('huawei','華爲科技有限公司','華爲小店','e10adc3949ba59abbe56e057f20f883e','0','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('itcast','傳智播客教育科技有限公司','傳智播客','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('itheima','黑馬程序員','黑馬程序員','e10adc3949ba59abbe56e057f20f883e','0','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('luoji','羅技科技有限公司','羅技小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('oppo','OPPO科技有限公司','OPPO官方旗艦店','e10adc3949ba59abbe56e057f20f883e','0','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('ourpalm','掌趣科技股份有限公司','掌趣小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('qiandu','千度科技','千度小店','e10adc3949ba59abbe56e057f20f883e','2','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('sina','新浪科技有限公司','新浪官方旗艦店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('xiaomi','小米科技','小米官方旗艦店','e10adc3949ba59abbe56e057f20f883e','1','西安市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('yijia','宜家家居','宜家家居旗艦店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');

create index idx_seller_name_sta_addr on tb_seller(name,status,address);

（一）全值匹配

全值匹配 ，對索引中全部列都指定具體值，該狀況下，索引生效，執行效率高。

explain select * from tb_seller where name='小米科技' and status='1' and address='北京市'\G;

（二）最左前綴法則

若是用多個字段進行查找，要遵照最左前綴法則。指的是查詢從索引的最左列開始，而且不跳過索引中的列。

注意：和查詢時使用的字段順序無關，是由建立索引時的字段順序決定的。

匹配最左前綴法則，會走索引：

違反最左前綴法則 ， 索引失效：

若是符合最左法則，可是出現跳躍某一列，只有最左列索引生效：

ps:

此處還能夠這樣使用：

select * from tb_seller where address='北京市' and status='1' and name='小米科技'

即：和查詢時使用的字段順序無關，是由建立索引時的字段順序決定的

（三）範圍查詢右邊的列，不能使用索引

範圍查詢右邊的列，不能使用索引 。

根據前面的兩個字段name, status 查詢是走索引的，可是最後一個條件address 沒有用到索引。

（四）不要在索引列上進行運算操做

不要在索引列上進行運算操做， 索引將失效。

（五）字符串要加單引號

字符串不加單引號，形成索引失效。

因爲在查詢時，沒有對字符串加單引號，MySQL的查詢優化器會自動的進行類型轉換，形成索引失效。

其實這個問題的根本緣由仍是屬於在索引列上進行運算操做從而致使的索引失效。

（六） 儘可能使用覆蓋索引

儘可能使用覆蓋索引（只訪問索引的查詢（索引列徹底包含查詢列）），減小select * 。

若是查詢列超出索引列，則會下降性能。

ps:

using index ：使用覆蓋索引的時候就會出現

using where：在查找使用索引的狀況下，須要回表去查詢所需的數據

using index condition：查找使用了索引，可是須要回表查詢數據

using index ; using where：查找使用了索引，可是須要的數據都在索引列中能找到，因此不須要回表查詢數據

（七）用or分割開的條件

用or分割開的條件， 若是or前的條件中的列有索引，然後面的列中沒有索引，那麼涉及的索引都不會被用到。

示例，name字段是索引列 ， 而createtime不是索引列，中間是or進行鏈接是不走索引的 ：

explain select * from tb_seller where name='黑馬程序員' or createtime = '2088-01-01 12:00:00'\G;

（八）以%開頭的Like模糊查詢

若是僅僅是尾部模糊匹配，索引不會失效。若是是頭部模糊匹配，索引失效。

解決方案 ： 經過覆蓋索引來解決

（九）is NULL, is NOT NULL 有時索引失效

其實這個問題的緣由是：

在tb_seller表中，絕大部分記錄的name字段是not null；而不多有記錄的name字段是null，全部若是爲有某一條記錄的name字段爲null，那麼此時name字段的辨識度就會很高，所以會走索引。

t_user表也是一樣的緣由。

（十） in 走索引， not in 索引失效

（十一）單列索引和複合索引

儘可能使用複合索引，而少使用單列索引 。

建立複合索引:

create index idx_name_sta_address on tb_seller(name, status, address);

--就至關於建立了三個索引 ： 
name
name + status
name + status + address

建立單列索引：

create index idx_seller_name on tb_seller(name);
create index idx_seller_status on tb_seller(status);
create index idx_seller_address on tb_seller(address);

數據庫會選擇一個最優的索引（辨識度最高索引）來使用，並不會使用所有索引 。

使用複合索引的效率比使用多個單列索引的效率要高。

（十二）MySQL評估使用索引比全表更慢

若是MySQL評估使用索引比全表更慢，則不使用索引。

其實這個問題的緣由和第九點中的is NULL, is NOT NULL 有時索引失效的緣由是同樣的，關鍵點都是辨識度。

9、查看索引使用狀況

show status like 'Handler_read%';	

show global status like 'Handler_read%';

Handler_read_first：索引中第一條被讀的次數。若是較高，表示服務器正執行大量全索引掃描（這個值越低越好）。

Handler_read_key：若是索引正在工做，這個值表明一個行被索引值讀的次數，若是值越低，表示索引獲得的性能改善不高，由於索引不常用（這個值越高越好）。

Handler_read_next ：按照鍵順序讀下一行的請求數。若是你用範圍約束或若是執行索引掃描來查詢索引列，該值增長。

Handler_read_prev：按照鍵順序讀前一行的請求數。該讀方法主要用於優化ORDER BY ... DESC。

Handler_read_rnd ：根據固定位置讀一行的請求數。若是你正執行大量查詢並須要對結果進行排序該值較高。你可能使用了大量須要MySQL掃描整個表的查詢或你的鏈接沒有正確使用鍵。這個值較高，意味着運行效率低，應該創建索引來補救。

Handler_read_rnd_next：在數據文件中讀下一行的請求數。若是你正進行大量的表掃描，該值較高。一般說明你的表索引不正確或寫入的查詢沒有利用索引。

如有錯誤，歡迎指正！