MySQL的索引優化分析(一)

1、SQL分析

性能降低、SQL慢、執行時間長、等待時間長

• 查詢語句寫的差
• 索引失效關聯查詢太多join(設計缺陷)
  • 單值索引：在user表中給name屬性建立索引，create index idx_name on user(name);
  • 複合索引：在user表中給name、email屬性建立索引，create index idx_name_email on user(name,email);
• 服務器調優及各個參數設置(緩衝、線程數等)

二，join查詢

1，SQL執行順序

　　a）手寫SQL

    

　　b）機讀

   

　　c）總結

  

2，JOIN查詢

　　

a）建表語句

CREATE TABLE tbl_dept(
    id INT(11) NOT NULL AUTO_INCREMENT,
    deptName VARCHAR(30) DEFAULT NULL,
    locAdd VARCHAR(40) DEFAULT NULL,
    PRIMARY KEY(id)
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

CREATE TABLE tbl_emp (
    id INT(11) NOT NULL AUTO_INCREMENT,
    NAME VARCHAR(20) DEFAULT NULL,
    deptId INT(11) DEFAULT NULL,
    PRIMARY KEY (id),
    KEY fk_dept_Id (deptId)
    #CONSTRAINT 'fk_dept_Id' foreign key ('deptId') references 'tbl_dept'('Id')
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

INSERT INTO tbl_dept(deptName,locAdd) VALUES('RD',11);
INSERT INTO tbl_dept(deptName,locAdd) VALUES('HR',12);
INSERT INTO tbl_dept(deptName,locAdd) VALUES('MK',13);
INSERT INTO tbl_dept(deptName,locAdd) VALUES('MIS',14);
INSERT INTO tbl_dept(deptName,locAdd) VALUES('FD',15);

INSERT INTO tbl_emp(NAME,deptId) VALUES('z3',1);
INSERT INTO tbl_emp(NAME,deptId) VALUES('z4',1);
INSERT INTO tbl_emp(NAME,deptId) VALUES('z5',1);
INSERT INTO tbl_emp(NAME,deptId) VALUES('w5',2);
INSERT INTO tbl_emp(NAME,deptId) VALUES('w6',2);
INSERT INTO tbl_emp(NAME,deptId) VALUES('s7',3);
INSERT INTO tbl_emp(NAME,deptId) VALUES('s8',4);
INSERT INTO tbl_emp(NAME,deptId) VALUES('s9',51);

View Code

b）知足條件的join語句

#左鏈接
SELECT * FROM tbl_dept t1 LEFT JOIN tbl_emp t2 on t1.id = t2.deptId;
#右鏈接
SELECT * FROM tbl_dept t1 RIGHT JOIN tbl_emp t2 on t1.id = t2.deptId;
#內鏈接(交集)
SELECT * FROM tbl_dept t1 INNER JOIN tbl_emp t2 on t1.id = t2.deptId;
#左鏈接(只取A獨有的)
SELECT * FROM tbl_dept t1 LEFT JOIN tbl_emp t2 on t1.id = t2.deptId WHERE t2.deptId is NULL;
#右鏈接(只取B獨有的)
SELECT * FROM tbl_dept t1 RIGHT JOIN tbl_emp t2 on t1.id = t2.deptId WHERE t1.id is NULL; 
#A和B均有
SELECT * FROM tbl_dept t1 LEFT JOIN tbl_emp t2 on t1.id = t2.deptId
UNION 
SELECT * FROM tbl_dept t1 RIGHT JOIN tbl_emp t2 on t1.id = t2.deptId;
#A和B均是獨有
SELECT * FROM tbl_dept t1 LEFT JOIN tbl_emp t2 on t1.id = t2.deptId WHERE t2.deptId is NULL
UNION
SELECT * FROM tbl_dept t1 RIGHT JOIN tbl_emp t2 on t1.id = t2.deptId WHERE t1.id is NULL;

3、索引

1，索引是什麼

• 索引(Index)是幫助MySQL高效獲取數據的數據結構。
• 排好序的快速查找數據結構，即索引 = 排序 + 查找
• 通常來講索引自己佔用內存空間也很大，不可能所有存儲在內存中，所以索引每每以文件形式存儲在硬盤上
• 彙集索引，次要索引，覆蓋索引，複合索引，前綴索引，惟一索引默認都是使用B+樹索引，統稱索引。固然，除了B+樹這種類型的索引以外，還有哈希索引(hash index)等。

2，索引原理

3，索引優劣勢

a)索引的優點

• 索引能提升數據檢索的效率，下降數據庫的IO成本
• 經過建立惟一性索引，能夠保證數據庫表中每一行數據的惟一性
• 在使用分組和排序子句進行數據檢索時，一樣能夠顯著減小查詢中分組和排序的時間
• 加速兩個表之間的鏈接，通常在外鍵上建立索引

b)劣勢

• 實際上索引也是一張表，該表保存了主鍵和索引字段，並指向實體表的記錄，因此索引列也是要佔用空間的
• 雖然索引大大提升了查詢速度，同時卻也會下降更新表的速度，如對錶insert、update和delete。由於更新表時，不只要保存數據，還要保存一下索引文件。
• 索引只是提升效率的一個因素，若是你的MySQL有大數據量的表，就須要花時間研究創建優秀的索引，或優化查詢語句

4，MySQL索引分類

1. 普通索引：是最基本的索引，它沒有任何限制，即一個索引只包含單個列，一個表能夠有多個單列索引；建議一張表索引不要超過5個，優先考慮複合索引
2. 惟一索引：與前面的普通索引相似，不一樣的就是：索引列的值必須惟一，但容許有空值。若是是組合索引，則列值的組合必須惟一
3. 主鍵索引：是一種特殊的惟一索引，一個表只能有一個主鍵，不容許有空值。通常是在建表的時候同時建立主鍵索引
4. 複合索引：指多個字段上建立的索引，只有在查詢條件中使用了建立索引時的第一個字段，索引纔會被使用。使用組合索引時遵循最左前綴集合
5. 全文索引：主要用來查找文本中的關鍵字，而不是直接與索引中的值相比較。fulltext索引跟其它索引大不相同，它更像是一個搜索引擎，而不是簡單的where語句的參數匹配

5，MySQL索引語法

• 建立索引

CREATE [UNIQUE] INDEX  index_name ON mytable(column_name(length));

• 刪除索引

DROP INDEX index_name ON mytable;

• 查看索引(\G表示將查詢到的橫向表格縱向輸出，方便閱讀)

SHOW INDEX FROM table_name\G

• 採用alter方式添加索引

#該語句添加一個主鍵，這意味着索引值必須是惟一的，且不能爲NULL。
ALTER TABLE tbl_name ADD PRIMARY KEY(column_list)
#這條語句建立索引的值必須是惟一的（除了NULL外，NULL可能會出現屢次）
ALTER TABLE tbl_name ADD UNIQUE index_name(column_list)
#添加普通索引，索引值可出現屢次。
ALTER TABLE tbl_name ADD INDEX index_name(column_list)
#該語句指定了索引爲FULLTEXT，用於全文索引。
ALTER TABLE tbl_name ADD FULLTEXT index_name(column_list)

6，MySQL的索引結構

　　詳情可查看：多路查找樹(B-Tree，B+Tree，B*Tree)

a）B-Tree與B+Tree的區別

　　B-樹的關鍵字（數據項）和記錄是放在一塊兒的； B+樹的非葉子節點中只有關鍵字和指向下一個節點的索引， 記錄只放在葉子節點中。

b）B+Tree 與 BTree 的查找過程

1. 在 B 樹中， 越靠近根節點的記錄查找時間越快， 只要找到關鍵字便可肯定記錄的存在； 而 B+ 樹中每一個記錄的查找時間基本是同樣的， 都須要從根節點走到葉子節點， 並且在葉子節點中還要再比較關鍵字。
2. 從這個角度看 B 樹的性能好像要比 B+ 樹好， 而在實際應用中倒是 B+ 樹的性能要好些。 由於 B+ 樹的非葉子節點不存放實際的數據，這樣每一個節點可容納的元素個數比 B 樹多， 樹高比 B 樹小， 這樣帶來的好處是減小磁盤訪問次數。
3. 儘管 B+ 樹找到一個記錄所需的比較次數要比 B 樹多， 可是一次磁盤訪問的時間至關於成百上千次內存比較的時間， 所以實際中B+ 樹的性能可能還會好些， 並且 B+樹的葉子節點使用指針鏈接在一塊兒， 方便順序遍歷（範圍搜索）， 這也是不少數據庫和文件系統使用 B+樹的緣故。

7，建立索引的場景

　　a）什麼時候須要建立索引

1. 主鍵自動創建惟一索引
2. 頻繁做爲查詢的條件的字段應該建立索引
3. 查詢中與其餘表關聯的字段，外鍵關係創建索引
4. 頻繁更新的字段不適合建立索引
5. Where 條件裏用不到的字段不建立索引
6. 單間/組合索引的選擇問題（在高併發下傾向建立組合索引）
7. 查詢中排序的字段，排序字段若經過索引去訪問將大大提升排序的速度
8. 查詢中統計或者分組字段

　　b）什麼時候不建立索引

1. 表記錄太少
2. 常常增刪改的表
3. 數據重複且分佈平均的表字段。若是某個數據列包含許多重複的內容，爲它創建索引就沒有太大的實際效果。

4、Explain

1，做用

1. 表的讀取順序（id 字段，越大優先級越高）
2. 數據讀取操做的操做類型（select_type 字段）
3. 哪些索引可使用（possible_keys 字段）
4. 哪些索引被實際使用（keys 字段）
5. 表之間的引用（ref 字段）
6. 每張表有多少行被優化器查詢（rows 字段）

2，id

• id相同，執行順序由上至下
• id不一樣，若是是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行
• id相同不一樣，同時存在：id若是相同，能夠認爲是一組，從上往下順序執行；在全部組中，id值越大，優先級越高，越先執行；衍生=DERIVED

       

2，select_type

　　select_type：查詢的類型，主要用於區別普通查詢、聯合查詢、子查詢等複雜查詢

1. SIMPLE：簡單的select查詢，查詢中不包含子查詢或者UNION
2. PRIMARY：查詢中若包含任何複雜的子部分，最外層查詢則被標記爲PRIMARY
3. SUBQUERY：在SELECT或者WHERE列表中包含了子查詢
4. DERIVED：在FROM列表中包含的子查詢被標記爲DERIVED（衍生）MySQL會遞歸執行這些子查詢，把結果放在臨時表裏
5. UNION：若第二個SELECT出如今UNION以後，則被標記爲UNION；若UNION包含在FROM子句的子查詢中，外層SELECT將被標記爲：DERIVED
6. UNION RESULT：從UNION表獲取結果的SELECT

3，table

　　table：顯示這一行的數據是關於哪張表的

4，type

　　type：訪問類型排列，顯示查詢使用了何種類型，其中從好到壞依次是：system>const>eq_ref>ref>fultext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>ALL。其中，相比比較重要的指標爲：system > const > eq_ref > ref > range > index > ALL

• system：表只有一行記錄（等於系統表），這是const類型的特例，平時不會出現，這個也能夠忽略不計
• const：表示經過索引一次就能找到了，const用於比較primary key或者unique索引。由於只匹配一行數據，因此很快。如將主鍵置於where列表中，MySQL就能將該查詢轉換爲一個常量　　

　　

• eq_ref：惟一性索引，對於每一個索引建，表中只有一條記錄與之匹配，常見於主鍵或惟一索引掃描

　　

• ref：非惟一索引掃描，返回匹配某個單獨值的全部行。本質上也是一種索引訪問，它返回全部匹配某個單獨值的行。不過，它可能找到多個符合條件的行，因此它應該屬於查找和掃描的混合體

　　

• range：只檢索給定範圍的行，使用一個索引來選擇行。key列顯示使用了哪一個索引，通常就是你的where語句中出現了between、<、>、in等的查詢，這種範圍掃描索引比全表掃描要好，由於他只須要開始索引的某一個點，而結束於另外一點，不用掃描所有索引

　　

• index：Full Index Scan，index與ALL區別爲index類型只遍歷索引樹。這一般比ALL快，由於索引文件一般比數據文件小。(也就是說雖然all和index都是讀全表，但index是從索引中讀取的，而all是從硬盤數據庫文件中讀的)

　　

• ALL：Full Table Scan，將遍歷全表以找到匹配的行(全表掃描)

　　

5，possible_keys

• 顯示可能應用在這張表上的索引，一個或多個
• 若查詢涉及的字段上存在索引，則該索引將被列出，但不必定被查詢實際使用

6，key

• 實際使用的索引，若是爲null，則沒有使用索引
• 若查詢中使用了覆蓋索引，則該索引僅出如今key列表中

　　

7，key_len

• 表示索引中使用的字節數，可經過該列計算查詢中使用的索引的長度。在不損失精確性的狀況下，長度越短越好
• key_len顯示的值爲索引最大可能長度，並不是實際使用長度，即key_len是根據表定義計算而得，不是經過表內檢索出的

 　　

8，ref

• 顯示索引哪一列被使用了，若是可能的話，最好是一個常數。哪些列或常量被用於查找索引列上的值
• 由key_len可知t1表的的索引idx_col1_col2被充分使用，t1表的col1匹配t2表的col1，t1表的col2匹配一個常量('ac')

　　

9，rows

　　根據表統計信息及索引選用狀況，大體估算出找到所需的記錄所須要讀取的行數

　　

10，Extra

a）Using filesort(文件排序)

• 在使用order by關鍵字的時候，若是待排序的內容不能由所使用的索引直接完成排序的話，那麼mysql有可能就要進行文件排序
• filesort是經過相應的排序算法,將取得的數據在內存中進行排序
• MySQL須要將數據在內存中進行排序，所使用的內存區域也就是咱們經過sort_buffer_size 系統變量所設置的排序區

　　

b）Using temporary(建立臨時表)

• using temporary通常出如今多張表的數據須要排序的狀況下. MySQl會先使用using temporary保存臨時數據, 而後再在臨時表上使用filesort進行排序
• 若是有ORDER BY子句和一個不一樣的GROUP BY子句, 或者若是ORDER BY或GROUP BY中的字段都來自其餘的表而非鏈接順序中的第一個表的話, 就會建立一個臨時表了。
• MySQL首先建立heap引擎的臨時表, 若是臨時的數據過多, 超過max_heap_table_size配置的大小, 會自動把臨時錶轉換成MyISAM引擎的表來使用

　　

c）Using indexing(覆蓋索引)

• 表示相應的select操做中使用了覆蓋索引（Coveing Index），避免訪問了表的數據行。

• 若是同時出現using where，代表索引被用來執行索引鍵值的查找

• 若是沒有同時出現using where，代表索引用來讀取數據而非執行查找動做　　

　　

覆蓋索引:
　　理解方式一：就是select的數據列只用從索引中就可以取得，沒必要讀取數據行，MySQL能夠利用索引返回select列表中的字段，而沒必要根據索引再次讀取數據文件，換句話說查詢列要被所建的索引覆蓋。
　　理解方式二：索引是高效找到行的一個方法，可是通常數據庫也能使用索引找到一個列的數據，所以它沒必要讀取整個行。畢竟索引葉子節點存儲了它們索引的數據；當能經過讀取索引就能夠獲得想要的數據，那就不須要讀取行了。一個索引包含了（或覆蓋了）知足查詢結果的數據就叫作覆蓋索引。
　　注意：若是要使用覆蓋索引，必定要注意select列表中只取出須要的列，不可select * ，由於若是將全部字段一塊兒作索引會致使索引文件過大，查詢性能降低。

d）Using where

　　表示使用了where過濾

e）Using join buffer

　　表示使用了鏈接緩存

f）impossible where

　　where子句的值老是false，不能用來獲取任何元組

　　

g）select tables optimized away

　　在沒有GROUP BY子句的狀況下，基於索引優化MIN/MAX操做或者對於MyISAM存儲引擎優化COUNT(*)操做，沒必要等到執行階段再進行計算，查詢執行計劃生成的階段即完成優化。

　　

h）distinct

　　優化distinct，在找到第一匹配的元組後即中止找一樣值的工做