MySQL的索引優化分析(二)

1、索引優化

1，單表索引優化

建表

CREATE TABLE IF NOT EXISTS article(
    id INT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
    author_id INT(10) UNSIGNED NOT NULL,
    category_id INT(10) UNSIGNED NOT NULL,
    views INT(10) UNSIGNED NOT NULL,
    comments INT(10) UNSIGNED NOT NULL,
    title VARCHAR(255) NOT NULL,
    content TEXT NOT NULL
);

INSERT INTO article(author_id,category_id,views,comments,title,content)
VALUES
(1,1,1,1,'1','1'),
(2,2,2,2,'2','2'),
(1,1,3,3,'3','3');

View Code

查詢案例

• 查詢category_id爲1且comments 大於1的狀況下，views最多的article_id。
• 查詢語句：SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
• 分析語句：EXPLAIN SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;

　　

• 分析：可看到上述type爲ALL，證實未命中索引，而且Using filesort使用了文件排序。故而可進行優化到使用索引。

優化一：

• 建立索引：CREATE INDEX idx_article_ccv ON article(category_id,comments,views);
• 查看當前索引：SHOW INDEX FROM article;

　　

• 查看執行計劃：EXPLAIN SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;

　　

• 分析：(刪除索引：DROP INDEX idx_article_ccv ON article;)
  • 由於按照B+Tree索引的工做原理，先排序 category_id，若是遇到相同的 category_id 則再排序comments，若是遇到相同的 comments 則再排序 views。
  • 最左前綴匹配原則，當comments字段在聯合索引裏處於中間位置時，由於comments>1條件是一個範圍值（所謂 range），MySQL 沒法利用索引再對後面的views部分進行檢索，即 range 類型查詢字段後面的索引無效。
  • 若是將條件comments > 1改爲comments = 1，則當前索引爲類型爲ref，而且不存在filesort。可是不知足題意

優化二：

• 建立索引：create index idx_article_ccv on article(category_id, views);
• 查看當前索引：SHOW INDEX FROM article;

　　

• 再次查看執行計劃：EXPLAIN SELECT id, author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;

　　

• 可看到此時知足條件，爲方便後續測試此時依然刪除當前索引：DROP INDEX idx_article_ccv ON article;

2，兩表索引優化

建表

CREATE TABLE IF NOT EXISTS class(
    id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    card INT(10) UNSIGNED NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS book(
    bookid INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    card INT(10) UNSIGNED NOT NULL,
    PRIMARY KEY(bookid)
);

INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO class(card) VALUES(FLOOR(1+(RAND()*20)));

INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO book(card) VALUES(FLOOR(1+(RAND()*20)));

View Code

查詢案例

• 實現兩表的鏈接，鏈接條件是 class.card = book.card
• 查詢語句：SELECT * FROM class LEFT JOIN book ON class.card = book.card;
• 分析語句：EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;

　　

• 分析：type 有 ALL ，rows 爲表中數據總行數，說明 class 和 book 進行了全表檢索

添加右表索引

• CREATE INDEX idx_book_card ON book(card);
• 分析語句：EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;

　　

•  分析：知足條件，故而刪除當前索引，方便後續測試：DROP INDEX idx_book_card ON book;
  • 這是由左鏈接特性決定的。LEFT JOIN條件用於肯定如何從右表搜索行，左邊必定都有，因此右邊是咱們的關鍵點，必定須要創建索引。
  • 左錶鏈接右表，則須要拿着左表的數據去右表裏面查，索引須要在右表中創建索引

添加左表索引

• CREATE INDEX idx_class_card ON class(card);
• 分析語句：EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;

　　

• 分析：有上圖可看出來索引未起到太大的做用，由於是左鏈接。左表驅動右邊的時候因爲左表不論如何都須要循環遍歷，故而rows仍是原來的，其實這樣並無太大的效果
• 將左鏈接轉成右鏈接：EXPLAIN SELECT * FROM class RIGHT JOIN book ON class.card = book.card;

　　

• 分析：知足條件方便，後續測試刪除當前索引：DROP INDEX idx_class_card ON class
  • 這是由於RIGHT JOIN條件用於肯定如何從左表搜索行，右邊必定都有，因此左邊是咱們的關鍵點，必定須要創建索引。
  • class RIGHT JOIN book ：book 裏面的數據必定存在於結果集中，咱們須要拿着 book 表中的數據，去 class 表中搜索，因此索引須要創建在 class 表中

3，三表索引優化

建表

CREATE TABLE IF NOT EXISTS phone(
    phoneid INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    card INT(10) UNSIGNED NOT NULL,
    PRIMARY KEY(phoneid)
)ENGINE=INNODB;

INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));
INSERT INTO phone(card) VALUES(FLOOR(1+(RAND()*20)));

View Code

查詢案例：

• 實現三表聯查：SELECT * FROM class LEFT JOIN book ON class.card = book.card LEFT JOIN phone ON book.card = phone.card
• 分析語句：EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card LEFT JOIN phone ON book.card = phone.card

　　

• 結論：
  • type 有ALL，rows 爲表數據總行數，說明 class、 book 和 phone 表都進行了全表檢索
  • Extra 中 Using join buffer ，代表鏈接過程當中使用了 join 緩衝區

建立索引：

• ALTER TABLE book ADD INDEX x (card);
  ALTER TABLE phone ADD INDEX y (card);

• 分析語句：EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card LEFT JOIN phone ON book.card = phone.card

　　

• 分析：進行 LEFT JOIN ，永遠都在右表的字段上創建索引

4，總結

　　將 left join 看做是兩層嵌套 for 循環

1. 儘量減小Join語句中的NestedLoop的循環總次數；
2. 永遠用小結果集驅動大的結果集（在大結果集中創建索引，在小結果集中遍歷全表）；
3. 優先優化NestedLoop的內層循環；
4. 保證Join語句中被驅動表上Join條件字段已經被索引；
5. 當沒法保證被驅動表的Join條件字段被索引且內存資源充足的前提下，不要太吝惜JoinBuffer的設置；

2、索引失效

建立表：

CREATE TABLE staffs(
    id INT PRIMARY KEY AUTO_INCREMENT,
    `name` VARCHAR(24)NOT NULL DEFAULT'' COMMENT'姓名',
    `age` INT NOT NULL DEFAULT 0 COMMENT'年齡',
    `pos` VARCHAR(20) NOT NULL DEFAULT'' COMMENT'職位',
    `add_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT'入職時間'
)CHARSET utf8 COMMENT'員工記錄表';

INSERT INTO staffs(`name`,`age`,`pos`,`add_time`) VALUES('z3',22,'manager',NOW());
INSERT INTO staffs(`name`,`age`,`pos`,`add_time`) VALUES('July',23,'dev',NOW());
INSERT INTO staffs(`name`,`age`,`pos`,`add_time`) VALUES('2000',23,'dev',NOW());

View Code

1，索引失效準則

1. 全值匹配我最愛
2. 最佳左前綴法則：若是索引了多例，要遵照最左前綴法則。指的是查詢從索引的最左前列開始而且不跳過索引中的列。
3. 不在索引列上作任何操做（計算、函數、（自動or手動）類型轉換），會致使索引失效而轉向全表掃描
4. 存儲引擎不能使用索引中範圍條件右邊的列
5. 儘可能使用覆蓋索引（只訪問索引的查詢（索引列和查詢列一致）），減小select *
6. mysql在使用不等於（!=或者<>）的時候沒法使用索引會致使全表掃描(並不絕對，需考慮成本問題，例如id!=''時仍是會用到索引的)
7. is null，is not null 也沒法使用索引（並不絕對，需考慮成本問題）
8. like以通配符開頭（’%abc…’）mysql索引失效會變成全表掃描操做(若是是'a%'則使用range索引)
9. 字符串不加引號索引失效
10. 少用or，用它鏈接時會索引失效

2，索引失效案例

a)建立複合索引

#建立複合索引
ALTER TABLE staffs ADD INDEX index_staffs_nameAgePos(`name`,`age`,`pos`); #查看索引 SHOW INDEX FROM staffs;

　　

b)where條件匹配

• 當順序匹配時：

　　

• 當不存在最左索引（name）時：能夠看到此時索引失效

　　

• 當中間索引不存在（age）時：能夠看到此時有效索引只有一個const，即：只有name有效

　　

• 當再索引列上計算或者使用函數時，會致使索引失效：使用left(name,4)='July'

　　

• 當使用範圍索引以後，後續的索引就會失效：name條件不變，把age由原來的等於變成大於，此時索引類型就由ref -> range

　　

• 儘可能使用覆蓋索引（只訪問索引的查詢（索引列和查詢列一致）），減小 select *

　　

• like中使用%的位置決定是否使用索引(若是%在左邊或者左右都有索引會失效，若是%只在右邊索引有效)

　　

• • 若是確實是須要將%放在左邊可採用覆蓋索引優化(只查詢須要的列並命中到索引上)

　　

• 字符串不加單引號索引失效：name=2000和name='2000'

　　

• 少用or，用它鏈接時會索引失效

　　

• mysql在使用不等於（!=或者<>）的時候沒法使用索引會致使全表掃描(固然也並不絕對，這裏有一個回執成本問題)

　　

• is null，is not null 會致使索引失效：key = null 表示索引失效(並不絕對，會考慮成本問題)

　　

注意在in、!=、is null和is not null，到底何時索引，何時採用全表掃描呢？　詳情描述請點擊查看

成本。對於使用二級索引（innodb）進行查詢來講，成本組成主要有兩個方面：
    讀取二級索引記錄的成本
    將二級索引記錄執行回表操做，也就是到聚簇索引中找到完整的用戶記錄的操做所付出的成本。
很顯然，要掃描的二級索引記錄條數越多，那麼須要執行的回表操做的次數也就越多，達到了某個比例時，使用二級索引執行查詢的成本也就超過了全表掃描的成本
（舉一個極端的例子，比方說要掃描的所有的二級索引記錄，那就要對每條記錄執行一遍回表操做，天然不如直接掃描聚簇索引來的快）。
因此MySQL優化器在真正執行查詢以前，對於每一個可能使用到的索引來講，都會預先計算一下須要掃描的二級索引記錄的數量。因此對於以上三種查詢條件是否會命中索引就取決於二級索引查詢的成本與全局查詢成本的高低。

3、索引案例

1，建表

create table test03(
    id int primary key not null auto_increment,
    c1 char(10),
    c2 char(10),
    c3 char(10),
    c4 char(10),
    c5 char(10)
);

insert into test03(c1,c2,c3,c4,c5) values ('a1','a2','a3','a4','a5');
insert into test03(c1,c2,c3,c4,c5) values ('b1','b2','b3','b4','b5');
insert into test03(c1,c2,c3,c4,c5) values ('c1','c2','c3','c4','c5');
insert into test03(c1,c2,c3,c4,c5) values ('d1','d2','d3','d4','d5');
insert into test03(c1,c2,c3,c4,c5) values ('e1','e2','e3','e4','e5');
#建立複合索引
create index idx_test03_c1234 on test03(c1,c2,c3,c4);

　　

2，案例

#只有where
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c3='a3' AND c4='a4';
EXPLAIN SELECT * FROM test03 WHERE c4='a4' AND c3='a3' AND c2='a2' AND c1='a1';
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c3>'a3' AND c4='a4';
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c4>'a4' AND c3='a3';
#where條件與order by 結合
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c4='a4' ORDER BY c3;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c3;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c4;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c5='a5' ORDER BY c2, c3;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c5='a5' ORDER BY c3, c2;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c2, c3;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c5='a5' ORDER BY c2, c3;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c5='a5' ORDER BY c3, c2;
#where與group by結合
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c4='a4' GROUP BY c2, c3;
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c4='a4' GROUP BY c3, c2;

3，案例分析

a）where查詢

　　

b）where與order by結合

　　

　　

c）where與group by

　　 

　　結論：group by 基本上都須要進行排序(使用狀況基本與order by相同，索引順序均會出如今where以後)，但凡使用不當，會有臨時表產生。

4，索引失效總結

a)建議

1. 對於單鍵索引，儘可能選擇針對當前query過濾性更好的索引
2. 在選擇組合索引的時候，當前query中過濾性最好的字段在索引字段順序中，位置越靠左越好。
3. 在選擇組合索引的時候，儘可能選擇能夠能包含當前query查詢條件中where子句更多字段的索引
4. 儘量經過分析統計信息和調整query的寫法來達到選擇合適索引的目的

b)案例