馬上就要到國慶節(jié)了，好是期待呀。最近一直忙成狗，急需一個長假調(diào)整一下自己的心境和狀態(tài)

期待.jpg

今天我們要說的是索引相關(guān)的知識，這也是數(shù)據(jù)庫的一個重點章節(jié)。趕緊準備好你的筆，跟著我一起勾畫重點吧，聽說這里要考哦~~~

索引的作用

1. 可以快速根據(jù)索引查找指定的記錄
2. 可以根據(jù)索引對記錄進行排序,可以用來order by 和group by
3. 可以將隨機IO轉(zhuǎn)變?yōu)轫樞騃O,索引是有順序的，先根據(jù)索引順序查詢，然后根據(jù)查找到的關(guān)鍵值定位記錄

三星系統(tǒng)

1. 索引將相關(guān)的記錄放在一起，獲得一星
2. 如果索引中的數(shù)據(jù)順序和查找中的排列順序一致則獲得兩星
3. 如果索引中的列包含查詢中全部列則獲得三星
   需要注意的是索引并不總是最好的工具，只有當(dāng)索引幫助存儲引擎快速查找到記錄帶來的好處大于其帶來的額外工作時，索引才是有效的
   一般情況下：
   小表：全表掃描
   中表（數(shù)據(jù)量還不是很大）：索引優(yōu)化
   大表（數(shù)據(jù)量超級大）：高級技術(shù)比如分區(qū)等

索引類型

mysql中索引類型有很多，索引的實現(xiàn)方式是通過存儲引擎實現(xiàn)的，而不是服務(wù)器層實現(xiàn)的

B-TREE索引

一般我們沒有特別指明索引類型的時候，說的索引應(yīng)該就是B-TREE索引，它使用B-TREE數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)的
因為索引是由存儲引擎實現(xiàn)的，所以不同的存儲引擎會通過不同的方式來使用B-TREE索引，MYISAM使用前綴壓縮技術(shù)使得索引更小，同時采用物理位置引用被索引的行（也就是說，通過索引直接就可以找到對應(yīng)的數(shù)據(jù)行記錄）INNODB則按照原數(shù)據(jù)格式進行存儲，同時根據(jù)主鍵引用被所以的行（也就是說通過索引首先會找到行的主鍵索引，然后通過主鍵索引找到具體的行）
B-TREE索引意味著所有存儲的數(shù)據(jù)記錄都是有順序的

b-tree數(shù)據(jù)結(jié)構(gòu).png

根據(jù)表的數(shù)據(jù)大小，B-TREE樹層級深度也將不同，其中每一個節(jié)點頁都包含了一個值以及左邊小于該值的子節(jié)點頁指針和大于該值的右節(jié)點頁指針，也就是規(guī)定了該值的上線和下限，而葉子頁的指針指向的是具體的數(shù)據(jù)，而不是其他的節(jié)點頁
在索引中，順序是非常重要的一個因素，索引對多個值進行排序的依據(jù)就是按照create table語句中定義索引時列的順序來實現(xiàn)的

B-TREE索引能使用的類型

全值匹配：所有列進行匹配
匹配最左前綴：匹配索引的第一列
匹配列前綴：匹配某一列的值開頭的部分
匹配范圍值：索引第一列范圍查找
精確匹配第一列，范圍匹配另外一列
因為索引樹中的節(jié)點是有順序的，所以除了按值查找之外，還可以對數(shù)據(jù)進行order by排序操作，但是使用B-TREE索引也有一定的限制：
如果不是按照索引的最左列開始查找，將無法使用索引
不能跳過索引中的列
如果查詢中有某個列的范圍查詢，則其后面的列都將無法使用索引進行查詢

hash索引

mysql索引是在存儲引擎層實現(xiàn)的，并沒有統(tǒng)一的標準，不同的存儲引擎實現(xiàn)的索引方式是不同的
對于hash索引，只能精確匹配所有列的值，因為存儲引擎將會把生成hash索引的所有列的值用來構(gòu)建hash code
在mysql中，只有memory引擎顯示支持hash索引，這也是它默認的索引類型，memory引擎同時也是支持非唯一hash索引的，當(dāng)出現(xiàn)hash沖突時，通過鏈表的方式解決沖突問題
hash索引基于hash表實現(xiàn)的，在它其中并不保存實際的值，而是保存hashcode->行的指針的鍵值對方式

hash索引數(shù)據(jù)結(jié)構(gòu).png

select url from t_urls where url_code = crc32(‘http://www.baidu.com’) and url = ‘http://www.baidu.com’;

這里如果發(fā)生了hash沖突，則根據(jù)url列值進行查找
上面創(chuàng)建偽hashcode索引列采用的是crc32算法，生成一個32位的數(shù)字，但是通常64位數(shù)字hash沖突會更少，可以自己定義一個算法：

select conv(right(md5('http://www.baidu.com'), 16), 16, 10);

如果語句中的索引列不是獨立的，那么這條語句就不能使用該列索引，也就是說索引列不能作為表達式的一部分或者不能作為函數(shù)的參數(shù)

select acter_id from actor where acter_id +1 = 5;
select ... where to_days(current_date) – to_days(date_col)<= 10

對于長度很長的列，創(chuàng)建索引時可以采用類似hash索引那樣的，自己建一個偽hashcode列，手動維護這個列，通過列值計算該列對應(yīng)的數(shù)字值并作為hash索引
以url列舉例，如果直接使用url，則整個列字段的字符串太長，占據(jù)太多空間，我們選擇為url創(chuàng)建一個url_code,用來計算crc32(url)得到的數(shù)字

create table urls {
    id int unsigned not null auto_increment,
    url varchar(255) not null,
    url_code int unsigned not null default 0
    primary key(id)
}

在插入或者更新url時，通過觸發(fā)器重新計算url_code的值

delimiter //
create trigger urls_insert_trigger before insert on urls for each row begin 
set new.url_code = crc32(new.url);
end;
//
create trigger urls_update_trigger before update on urls for each row begin 
set new.url_code = crc32(new.url);
end;
//
delimiter;

通過偽hashcode列與該列值來精確查詢某一條記錄

select * from urls where url_code = crc32(‘http://www.baidu.com’) and url = ‘http://www.baidu.com’;

全文索引

全文索引是一種特殊類型的索引，它查找的是文本中的關(guān)鍵字，而不是直接比較索引中的值，它與其他幾種類型的索引匹配方式完全不一樣，它存在許多需要注意的細節(jié)：如停用詞、詞干、復(fù)數(shù)、布爾搜索等，更加類似于搜索引擎要干的事情

前綴索引

通過比較列選擇性和索引選擇性來決定前綴的長度，對于mysql來說，不允許對text/blob列全值進行索引，但是我們可以通過在查詢時指定使用前綴來優(yōu)化此類查詢，比如排序時，避免磁盤臨時表排序
選擇性：不重復(fù)的索引值和數(shù)據(jù)表記錄總數(shù)的比值

select count(*) as count, city as city from t_city group by city order by city desc limit 10;

上面這條語句記錄了每一個城市出現(xiàn)的重復(fù)次數(shù)

select count(*) as count, left(city, 3) as pref from t_city group by pref order by pref desc limit 10;

還有一種選擇方式：計算列平均選擇性，并使前綴選擇性接近列選擇性

select count(distinct city) / count(*) from t_city;
select count(distinct left(city, 3)) / count(*) from t_city

前綴索引的創(chuàng)建方式

alter table sakila.city_demo add key city(7)
這樣就在sakila.city_demo表中創(chuàng)建了一個city前綴索引，索引長度為7個字符，
使用前綴索引的缺點是：前綴索引不能用來做order by 和group by操作，也無法用于作覆蓋掃描

后綴索引

還有一種是“反向索引”，針對像url這種類型的字符串列而言的，使用后綴來進行索引效果更佳，但是mysql本身并不支持后綴索引這種方式，所以我們可以通過將保存的url字符串反向存入數(shù)據(jù)庫并創(chuàng)建前綴索引的方式來實現(xiàn)所謂的后綴索引

選擇合適的索引順序

在B-TREE索引中，索引列的順序意味著索引從最左列進行排序，經(jīng)驗法則告訴我們可以將選擇性高的放在前面，當(dāng)不需要考慮排序和分組時，將選擇性高的索引列放在前面通常是非常好的
我們需要對多個列計算每個列對應(yīng)的選擇性，然后做出決策

select count(distinct staff_id) / count(*) as staff_id_selectivity,
count(distinct custom_id) /count(*) as custom_id_selectivity, count(*) from payment \G;

列選擇性.png

根據(jù)查詢結(jié)果來看，應(yīng)該將custom_id放在索引列staff_id前面
順序的索引會造成的潛在問題：
在高并發(fā)工作時，innoDB按主鍵順序插入可能會引起明顯的間隙鎖爭用

聚簇索引

聚簇索引其實是一種數(shù)據(jù)結(jié)構(gòu)，保存了B-TREE索引和數(shù)據(jù)行，數(shù)據(jù)表中的數(shù)據(jù)記錄都保存在葉子頁上,但是節(jié)點頁只包含了索引列
聚簇表示數(shù)據(jù)行與相鄰的鍵值緊湊的存儲在一起，

聚簇索引數(shù)據(jù)結(jié)構(gòu).png

在innoDB數(shù)據(jù)庫中，通過主鍵索引列來聚簇數(shù)據(jù)記錄，也就是說，在innoDB聚簇索引中，節(jié)點頁上保存的是行主鍵，如果沒有主鍵列，innoDB會選擇一個非空索引代替，如果也沒有這樣的索引，innoDB會創(chuàng)建一個隱式的主鍵來進行聚簇
在innodb中，沒有被用來做聚簇的索引，被稱為是二級索引，在索引中保存的并不是物理行的位置，而是行記錄的主鍵，需要根據(jù)二級索引找到行主鍵之后再到聚簇B-TREE中查找指定的行記錄
myisam引擎主鍵與其他索引實現(xiàn)相同，主鍵只是一個名稱為PRIMARY的非空索引。
myisam存儲數(shù)據(jù)就是按照數(shù)據(jù)的插入順序保存的，表存儲結(jié)構(gòu)的葉子節(jié)點上保存了當(dāng)前索引列值和物理行所在的位置
innodb通過B-TREE結(jié)構(gòu)保存數(shù)據(jù)表行的所有列記錄，二級索引通過保存主鍵值，在根據(jù)主鍵值在B-TREE結(jié)構(gòu)中查找物理行數(shù)據(jù)信息

聚集的數(shù)據(jù)有哪些優(yōu)點

1. 可以把相關(guān)的數(shù)據(jù)保存在一起，這樣在查找記錄時可以從磁盤上讀取少量的頁就能查到結(jié)果
2. 訪問數(shù)據(jù)更快，聚簇索引將索引和數(shù)據(jù)都保存在同一個B-TREE中，因此從聚簇索引獲取數(shù)據(jù)比非聚簇索引獲取數(shù)據(jù)要快
3. 使用覆蓋索引掃描的查詢，可以直接使用頁節(jié)點的主鍵值，無需再根據(jù)主鍵查找數(shù)據(jù)
   聚簇索引的缺點
   聚簇索引最大限度的提高了I/O密集型應(yīng)用的性能，但如果數(shù)據(jù)全部都放在內(nèi)存中，那么訪問的順序就沒那么重要了
4. 插入速度嚴重依賴于插入順序，按照主鍵的順序插入是加載數(shù)據(jù)到INNODB表中速度最快的方式
5. 更新聚簇索引列的代價很高，因為會強制每一個被更新的行移動到新的位置
   4． 基于聚簇索引的表在插入新行，或者主鍵被更新導(dǎo)致需要移動行的時候，可能面臨頁分裂的問題
6. 聚簇索引可能導(dǎo)致全表掃描變慢，尤其是行比較稀疏的時候，或者頁分裂導(dǎo)致數(shù)據(jù)存儲不連續(xù)的時候
7. 二級索引可能比想象的大，因為二級索引的葉子節(jié)點包含了引用行的主鍵列
8. 二級索引訪問需要兩次索引查找，找主鍵、找數(shù)據(jù)

延遲查詢

對于某些查詢，可以通過延遲查詢來優(yōu)化
explain select * from products where actor = ‘sean carrey’ and title like ‘%apollo%’\G
其中actor 與title 列建立了索引
這里無法對查詢進行索引覆蓋，因為查詢的列為全部列，不存在任何一個索引可以覆蓋所有列
改為延遲加載，添加索引覆蓋列(actor, title, prod_id)

explain select * from products inner join (
select prod_id from products where actor = ‘sean carrey’ and title like ‘%apollo%’)as t1 on (t1.prod_id = products.prod_id)

上面子查詢采用索引覆蓋，過濾prod_id,然后根據(jù)prod_id再到記錄中查找

覆蓋索引

如果一個索引包含所有需要查詢的字段的值，那么我們就稱之為覆蓋索引

覆蓋索引的好處

1. 索引條目通常遠小于數(shù)據(jù)行大小，所以如果只需要讀取索引，那mysql就會極大的減少數(shù)據(jù)訪問量
2. 因為索引是按照列值順序存儲的，所以順序查詢會比隨機從磁盤讀取數(shù)據(jù)的I/O要少的多
3. 一些存儲引擎如MYISAM在內(nèi)存中只緩存索引，數(shù)據(jù)則依賴于具體OS來緩存，因此訪問數(shù)據(jù)意味著還需要一次系統(tǒng)調(diào)用，采用覆蓋索引則減少了這樣的系統(tǒng)調(diào)用
4. 針對INNODB的聚簇索引，覆蓋索引可以杜絕二級索引根據(jù)主鍵值查找數(shù)據(jù)行記錄
   覆蓋索引必須要存儲索引列的值，而hash索引、空間索引、全文索引都不存儲索引列的值，所以mysql只能使用b-tree索引做覆蓋索引
   當(dāng)發(fā)起一個索引覆蓋查詢時，通過explain分析語句會看到extra Using index,這里的extra表示的是檢索數(shù)據(jù)的方式，需要與type進行區(qū)分，type index表示在對結(jié)果集進行排序時使用到了索引
   如果查詢的列沒有被索引覆蓋，也就是無法使用索引覆蓋查詢時，explain查詢分析出來extra Using where
   對于下面這條語句：

explain select * from products where actor=’seny carrey’ and title like ‘%apollo%’\G

存在兩個問題導(dǎo)致它無法使用覆蓋索引：

1. 沒有任何一個索引能夠覆蓋這個查詢，因為從表中選擇了所有列，而沒有任何索引覆蓋了所有列
2. mysql不能在索引中執(zhí)行l(wèi)ike操作，只是允許使用左前綴匹配的方式和一些簡單的值比較，上面的查詢語句可以通過延遲關(guān)聯(lián)來解決：

select * from product inner join(
    select prod_id from product where actor=’seny carrey’ and title like ‘a(chǎn)pollo%’
) as t1 on t1.prod_id = product.prod_id\G

使用索引掃描做排序

排序有兩種方式：直接通過排序、按索引順序掃描,如果explain出來的結(jié)果中的type為index，則表示使用到了索引掃描來做排序
orderby子句的列順序必須與索引列定義的順序完全一致（也就是說按照多個列進行排序，要么都升序，要么都降序），因為mysql是按照索引順序來組織記錄順序的，而order by 如果打破了這種規(guī)則那么就必須使用文件排序
如果查詢關(guān)聯(lián)多張表，則只有當(dāng)order by子句引用的字段全部為第一個表，才能使用索引做排序
還有一種情況就是如果索引前導(dǎo)列（where語句或者join子句中包含的索引第一列）設(shè)置為常量時，就可以使用索引進行排序,比如：
(rental_date,inventory_id,customer_id)為一個組合索引，則語句

select rental_id,staff_id from sakila.rental where rental_date=’2005-05-25’ order by inventory_id,customer_id

可以使用索引進行排序，雖然order by 子句不滿足索引的最左前綴要求，也可以用于查詢排序，因為索引第一列被設(shè)置成為了常量

下面列出不能使用索引做排序的查詢

1. 使用兩種不同的排序方向，但是索引列都是正序排列
   where rental_date=2005-05-25’ order by inventory_id desc,customer_id asc;
2. 引用不存在與索引中的列
   where rental_date=2005-05-25’ order by inventory_id,staff_id
3. where與order by中的列無法組合成索引的最左前綴
   where rental_date=’2005-05-25’ order by customer_id
4. 查詢在索引列的第一列為范圍查詢條件，所以mysql無法使用其他的索引列
   where rental_date > ‘2005-05-25’ order by inventory_id,customer_id
5. 索引列上存在多個等值條件，對于查詢來說其實就相當(dāng)于范圍查詢
   where rental_date = ‘2005-05-25’ and inventory_id in(1,2) order by customer_id

壓縮（前綴壓縮）索引

myisam使用前綴壓縮索引減少索引的大小，從而讓更多的索引能放入內(nèi)存，默認只壓縮字符串，但是也可以配置壓縮整數(shù)
myisam壓縮每個索引塊的方法是，先完全保存索引塊的第一個值，然后將其他值和第一個值進行比較得到相同的前綴的字節(jié)數(shù)和不同的后綴，把這部分存儲起來即可，比如：索引塊中第一個值為perform，第二個值為performance，那么第二個值的前綴壓縮后存儲的是7,ance這樣的形式
前綴索引無法通過二分查找只能從頭開始掃描，正序的掃描速度還不錯，但反序就不是很好了

冗余索引和重復(fù)索引

重復(fù)索引，具有相同類型、按照相同順序的索引，應(yīng)該避免，發(fā)現(xiàn)后立即刪除
冗余索引，(A,B)為索引，再創(chuàng)建索引(A)就是冗余索引，因為A索引只是AB索引的前綴索引，因此索引(AB)也可以當(dāng)做(A)來算
默認情況下在創(chuàng)建innodb二級索引時，主鍵索引已經(jīng)默認添加到該索引上了，例如(A, ID)其中id為主鍵索引
冗余索引必須是相同的類型，其他類型的索引，比如hash索引或者全文索引頁不會是B-TREE索引的冗余索引

索引和鎖

索引可以讓查詢鎖定更少的行，innodb只有在訪問行的時候才會對其加鎖，而索引能夠減少innodb訪問的行數(shù)，從而減少鎖的數(shù)量，但這只有在存儲引擎層過濾掉所有不需要的行時才有效

支持多種過濾條件

在有更多不同值的列上創(chuàng)建索引的選擇性會更好，在檢索時，我們可以將查詢用的多的列加入到索引中，對于索引前綴列不需要進行條件過濾時，通過in指定列值，IN的方式對查詢檢索是有效的，但是對order by則是無效的，比如存在(sex,country)這樣的索引，當(dāng)我們需要使用到該索引時，但又不需要對性別做出限制，那么我們可以通過and sex in (‘m’,’f’)的方式讓mysql選擇該列索引

避免多個范圍條件

針對這兩種查詢語句：

select actor_id from actor where actor_id > 45;
select actor_id from actor where actor_id in (1,4,49);

這兩種查詢語句的執(zhí)行效率是不同的，對于范圍查詢，mysql是無法使用范圍列后面的其他索引列了，但是對于多個等值條件查詢，則沒有這個限制

維護索引和表

找到并修復(fù)索引表

通過check table來檢查是否發(fā)生了表損壞，并通過repair table來修復(fù)表；但是如果存儲引擎不支持該命令，也可以通過alter table 重建表來達到修復(fù)目的
alter table innodb_tbl ENGINE=INNODB

更新索引統(tǒng)計信息

查詢優(yōu)化器通過兩個API來了解存儲引擎的索引值分布，通過這兩個API的結(jié)果來決定使用哪個索引進行查詢優(yōu)化
records_in_range();傳入兩個邊界值計算之間的記錄數(shù)
info();返回各種類型的數(shù)據(jù)包括索引基數(shù)（通過show index from table）
如果統(tǒng)計信息不準確，那么定會影響到查詢優(yōu)化器的優(yōu)化策略，通過analyze table重新生成統(tǒng)計信息

數(shù)據(jù)碎片類型

行碎片：數(shù)據(jù)行被存儲在多個地方的多個片段中
行間碎片：邏輯上順序的頁，在磁盤上不是順序的
剩余空間碎片：數(shù)據(jù)頁中大量的空余空間
通過optimize table 或者導(dǎo)出再導(dǎo)入的方式來重新整理數(shù)據(jù)，對于不支持該命令的存儲引擎，可以通過alter table tablename engine=<engine>來進行優(yōu)化
每種存儲引擎實現(xiàn)索引統(tǒng)計信息的方式不同，所以需要進行analyze table的頻率也不同：

1. memory引擎根本不存儲索引統(tǒng)計信息
2. myisam引擎將索引統(tǒng)計信息存儲在磁盤中，analyze table需要進行一次全索引掃描來計算索引基數(shù)
3. 直到mysql5.5，innodb也不在磁盤存儲索引統(tǒng)計信息，而是通過隨機的索引訪問進行評估，并將估算結(jié)果存在內(nèi)存中

mysql執(zhí)行狀態(tài)

通過show full processlist來查看mysql當(dāng)前處在哪一個狀態(tài)
sleep 線程正等待客戶端發(fā)起查詢請求
locked 在mysql服務(wù)層里，該線程正在等待表鎖
Analyzing and statistics 線程正在搜集存儲引擎的統(tǒng)計信息，并生成查詢執(zhí)行計劃
query 線程正在查詢
Copying to tmp table [on disk],線程正在執(zhí)行查詢，并將結(jié)果復(fù)制到一個臨時表中，這種狀態(tài)要么是在group by操作，要么是在文件排序操作，如果這個狀態(tài)后面還有on disk ，則表示mysql正在把一個內(nèi)存臨時表放到磁盤
sorting result 線程正在進行排序
Sending data 這個狀態(tài)有多重可能，有可能是線程之間在進行數(shù)據(jù)傳輸，或者正在生成結(jié)果集，或者向客戶端返回數(shù)據(jù)