MySQL性能優化——索引

原文地址：http://blog.codinglabs.org/articles/theory-of-mysql-index.html

InnoDB使用B+Tree做爲索引結構

最左前綴原理與相關優化

 

以employees.titles表爲例，下面先查看其上都有哪些索引：

1. SHOW INDEX FROM employees.titles;
2. +--------+------------+----------+--------------+-------------+-----------+-------------+------+------------+
3. | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Null | Index_type |
4. +--------+------------+----------+--------------+-------------+-----------+-------------+------+------------+
5. | titles | 0 | PRIMARY | 1 | emp_no | A | NULL | | BTREE |
6. | titles | 0 | PRIMARY | 2 | title | A | NULL | | BTREE |
7. | titles | 0 | PRIMARY | 3 | from_date | A | 443308 | | BTREE |
8. | titles | 1 | emp_no | 1 | emp_no | A | 443308 | | BTREE |
9. +--------+------------+----------+--------------+-------------+-----------+-------------+------+------------+

從結果中能夠到titles表的主索引爲<emp_no, title, from_date>，還有一個輔助索引<emp_no>。爲了不多個索引使事情變複雜（MySQL的SQL優化器在多索引時行爲比 較複雜），這裏咱們將輔助索引drop掉：

1. ALTER TABLE employees.titles DROP INDEX emp_no;

這樣就能夠專心分析索引PRIMARY的行爲了。

狀況一：全列匹配。

1. EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title='Senior Engineer' AND from_date='1986-06-26';
2. +----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
5. | 1 | SIMPLE | titles | const | PRIMARY | PRIMARY | 59 | const,const,const | 1 | |
6. +----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+

很明顯，當按照索引中全部列進行精確匹配（這裏精確匹配指「=」或「IN」匹配）時，索引能夠被用到。這裏有一點須要注意，理論上索引對順序是敏感 的，可是因爲MySQL的查詢優化器會自動調整where子句的條件順序以使用適合的索引，例如咱們將where中的條件順序顛倒：

1. EXPLAIN SELECT * FROM employees.titles WHERE from_date='1986-06-26' AND emp_no='10001' AND title='Senior Engineer';
2. +----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+
5. | 1 | SIMPLE | titles | const | PRIMARY | PRIMARY | 59 | const,const,const | 1 | |
6. +----+-------------+--------+-------+---------------+---------+---------+-------------------+------+-------+

效果是同樣的。

狀況二：最左前綴匹配。

1. EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001';
2. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------+
5. | 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const | 1 | |
6. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------+

當查詢條件精確匹配索引的左邊連續一個或幾個列時，如<emp_no>或<emp_no, title>，因此能夠被用到，可是隻能用到一部分，即條件所組成的最左前綴。上面的查詢從分析結果看用到了PRIMARY索引，可是 key_len爲4，說明只用到了索引的第一列前綴。

狀況三：查詢條件用到了索引中列的精確匹配，可是中間某個條件未提供。

1. EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND from_date='1986-06-26';
2. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+
5. | 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const | 1 | Using where |
6. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+

此時索引使用狀況和狀況二相同，由於title未提供，因此查詢只用到了索引的第一列，然後面的from_date雖然也在索引中，可是因爲 title不存在而沒法和左前綴鏈接，所以須要對結果進行掃描過濾from_date（這裏因爲emp_no惟一，因此不存在掃描）。若是想讓 from_date也使用索引而不是where過濾，能夠增長一個輔助索引<emp_no, from_date>，此時上面的查詢會使用這個索引。除此以外，還可使用一種稱之爲「隔離列」的優化方法，將emp_no與from_date 之間的「坑」填上。

首先咱們看下title一共有幾種不一樣的值：

1. SELECT DISTINCT(title) FROM employees.titles;
2. +--------------------+
3. | title |
4. +--------------------+
5. | Senior Engineer |
6. | Staff |
7. | Engineer |
8. | Senior Staff |
9. | Assistant Engineer |
10. | Technique Leader |
11. | Manager |
12. +--------------------+

只有7種。在這種成爲「坑」的列值比較少的狀況下，能夠考慮用「IN」來填補這個「坑」從而造成最左前綴：

1. EXPLAIN SELECT * FROM employees.titles
2. WHERE emp_no='10001'
3. AND title IN ('Senior Engineer', 'Staff', 'Engineer', 'Senior Staff', 'Assistant Engineer', 'Technique Leader', 'Manager')
4. AND from_date='1986-06-26';
5. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
6. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
7. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
8. | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 59 | NULL | 7 | Using where |
9. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

此次key_len爲59，說明索引被用全了，可是從type和rows看出IN實際上執行了一個range查詢，這裏檢查了7個key。看下兩種查詢的性能比較：

1. SHOW PROFILES;
2. +----------+------------+-------------------------------------------------------------------------------+
3. | Query_ID | Duration | Query |
4. +----------+------------+-------------------------------------------------------------------------------+
5. | 10 | 0.00058000 | SELECT * FROM employees.titles WHERE emp_no='10001' AND from_date='1986-06-26'|
6. | 11 | 0.00052500 | SELECT * FROM employees.titles WHERE emp_no='10001' AND title IN ... |
7. +----------+------------+-------------------------------------------------------------------------------+

「填坑」後性能提高了一點。若是通過emp_no篩選後餘下不少數據，則後者性能優點會更加明顯。固然，若是title的值不少，用填坑就不合適了，必須創建輔助索引。

狀況四：查詢條件沒有指定索引第一列。

1. EXPLAIN SELECT * FROM employees.titles WHERE from_date='1986-06-26';
2. +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+
5. | 1 | SIMPLE | titles | ALL | NULL | NULL | NULL | NULL | 443308 | Using where |
6. +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+

因爲不是最左前綴，索引這樣的查詢顯然用不到索引。

狀況五：匹配某列的前綴字符串。

1. EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title LIKE 'Senior%';
2. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
5. | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 56 | NULL | 1 | Using where |
6. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

此時能夠用到索引，可是若是通配符不是隻出如今末尾，則沒法使用索引。（原文表述有誤，若是通配符%不出如今開頭，則能夠用到索引，但根據具體狀況不一樣可能只會用其中一個前綴）

狀況六：範圍查詢。

1. EXPLAIN SELECT * FROM employees.titles WHERE emp_no < '10010' and title='Senior Engineer';
2. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
5. | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 4 | NULL | 16 | Using where |
6. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

範圍列能夠用到索引（必須是最左前綴），可是範圍列後面的列沒法用到索引。同時，索引最多用於一個範圍列，所以若是查詢條件中有兩個範圍列則沒法全用到索引。

1. EXPLAIN SELECT * FROM employees.titles
2. WHERE emp_no < '10010'
3. AND title='Senior Engineer'
4. AND from_date BETWEEN '1986-01-01' AND '1986-12-31';
5. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
6. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
7. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
8. | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 4 | NULL | 16 | Using where |
9. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

能夠看到索引對第二個範圍索引無能爲力。這裏特別要說明MySQL一個有意思的地方，那就是僅用explain可能沒法區分範圍索引和多值匹配，由於在type中這二者都顯示爲range。同時，用了「between」並不意味着就是範圍查詢，例以下面的查詢：

1. EXPLAIN SELECT * FROM employees.titles
2. WHERE emp_no BETWEEN '10001' AND '10010'
3. AND title='Senior Engineer'
4. AND from_date BETWEEN '1986-01-01' AND '1986-12-31';
5. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
6. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
7. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
8. | 1 | SIMPLE | titles | range | PRIMARY | PRIMARY | 59 | NULL | 16 | Using where |
9. +----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

看起來是用了兩個範圍查詢，但做用於emp_no上的「BETWEEN」實際上至關於「IN」，也就是說emp_no實際是多值精確匹配。能夠看到這個查詢用到了索引所有三個列。所以在MySQL中要謹慎地區分多值匹配和範圍匹配，不然會對MySQL的行爲產生困惑。

狀況七：查詢條件中含有函數或表達式。

很不幸，若是查詢條件中含有函數或表達式，則MySQL不會爲這列使用索引（雖然某些在數學意義上可使用）。例如：

1. EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND left(title, 6)='Senior';
2. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+
5. | 1 | SIMPLE | titles | ref | PRIMARY | PRIMARY | 4 | const | 1 | Using where |
6. +----+-------------+--------+------+---------------+---------+---------+-------+------+-------------+

雖然這個查詢和狀況五中功能相同，可是因爲使用了函數left，則沒法爲title列應用索引，而狀況五中用LIKE則能夠。再如：

 

1. EXPLAIN SELECT * FROM employees.titles WHERE emp_no - 1='10000';
2. +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+
5. | 1 | SIMPLE | titles | ALL | NULL | NULL | NULL | NULL | 443308 | Using where |
6. +----+-------------+--------+------+---------------+------+---------+------+--------+-------------+

顯然這個查詢等價於查詢emp_no爲10001的函數，可是因爲查詢條件是一個表達式，MySQL沒法爲其使用索引。看來MySQL尚未智能到 自動優化常量表達式的程度，所以在寫查詢語句時儘可能避免表達式出如今查詢中，而是先手工私下代數運算，轉換爲無表達式的查詢語句。

 

索引選擇性與前綴索引

既然索引能夠加快查詢速度，那麼是否是隻要是查詢語句須要，就建上索引？答案是否認的。由於索引雖然加快了查詢速度，但索引也是有代價的：索引文件 自己要消耗存儲空間，同時索引會加劇插入、刪除和修改記錄時的負擔，另外，MySQL在運行時也要消耗資源維護索引，所以索引並非越多越好。通常兩種情 況下不建議建索引。

第一種狀況是表記錄比較少，例如一兩千條甚至只有幾百條記錄的表，不必建索引，讓查詢作全表掃描就行了。至於多少條記錄纔算多，這個我的有我的的見解，我我的的經驗是以2000做爲分界線，記錄數不超過 2000能夠考慮不建索引，超過2000條能夠酌情考慮索引。

另外一種不建議建索引的狀況是索引的選擇性較低。所謂索引的選擇性（Selectivity），是指不重複的索引值（也叫基數，Cardinality）與表記錄數（#T）的比值：

Index Selectivity = Cardinality / #T

顯然選擇性的取值範圍爲(0, 1]，選擇性越高的索引價值越大，這是由B+Tree的性質決定的。例如，上文用到的employees.titles表，若是title字段常常被單獨查詢，是否須要建索引，咱們看一下它的選擇性：

1. SELECT count(DISTINCT(title))/count(*) AS Selectivity FROM employees.titles;
2. +-------------+
3. | Selectivity |
4. +-------------+
5. | 0.0000 |
6. +-------------+

title的選擇性不足0.0001（精確值爲0.00001579），因此實在沒有什麼必要爲其單獨建索引。

有一種與索引選擇性有關的索引優化策略叫作前綴索引，就是用列的前綴代替整個列做爲索引key，當前綴長度合適時，能夠作到既使得前綴索引的選擇性 接近全列索引，同時由於索引key變短而減小了索引文件的大小和維護開銷。下面以employees.employees表爲例介紹前綴索引的選擇和使 用。

從圖12能夠看到employees表只有一個索引<emp_no>，那麼若是咱們想按名字搜索一我的，就只能全表掃描了：

1. EXPLAIN SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido';
2. +----+-------------+-----------+------+---------------+------+---------+------+--------+-------------+
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
4. +----+-------------+-----------+------+---------------+------+---------+------+--------+-------------+
5. | 1 | SIMPLE | employees | ALL | NULL | NULL | NULL | NULL | 300024 | Using where |
6. +----+-------------+-----------+------+---------------+------+---------+------+--------+-------------+

若是頻繁按名字搜索員工，這樣顯然效率很低，所以咱們能夠考慮建索引。有兩種選擇，建<first_name>或<first_name, last_name>，看下兩個索引的選擇性：

1. SELECT count(DISTINCT(first_name))/count(*) AS Selectivity FROM employees.employees;
2. +-------------+
3. | Selectivity |
4. +-------------+
5. | 0.0042 |
6. +-------------+
7. SELECT count(DISTINCT(concat(first_name, last_name)))/count(*) AS Selectivity FROM employees.employees;
8. +-------------+
9. | Selectivity |
10. +-------------+
11. | 0.9313 |
12. +-------------+

<first_name>顯然選擇性過低，<first_name, last_name>選擇性很好，可是first_name和last_name加起來長度爲30，有沒有兼顧長度和選擇性的辦法？能夠考慮用 first_name和last_name的前幾個字符創建索引，例如<first_name, left(last_name, 3)>，看看其選擇性：

1. SELECT count(DISTINCT(concat(first_name, left(last_name, 3))))/count(*) AS Selectivity FROM employees.employees;
2. +-------------+
3. | Selectivity |
4. +-------------+
5. | 0.7879 |
6. +-------------+

選擇性還不錯，但離0.9313仍是有點距離，那麼把last_name前綴加到4：

1. SELECT count(DISTINCT(concat(first_name, left(last_name, 4))))/count(*) AS Selectivity FROM employees.employees;
2. +-------------+
3. | Selectivity |
4. +-------------+
5. | 0.9007 |
6. +-------------+

這時選擇性已經很理想了，而這個索引的長度只有18，比<first_name, last_name>短了接近一半，咱們把這個前綴索引 建上：

1. ALTER TABLE employees.employees
2. ADD INDEX `first_name_last_name4` (first_name, last_name(4));

此時再執行一遍按名字查詢，比較分析一下與建索引前的結果：

1. SHOW PROFILES;
2. +----------+------------+---------------------------------------------------------------------------------+
3. | Query_ID | Duration | Query |
4. +----------+------------+---------------------------------------------------------------------------------+
5. | 87 | 0.11941700 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
6. | 90 | 0.00092400 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
7. +----------+------------+---------------------------------------------------------------------------------+

性能的提高是顯著的，查詢速度提升了120多倍。

前綴索引兼顧索引大小和查詢速度，可是其缺點是不能用於ORDER BY和GROUP BY操做，也不能用於Covering index（即當索引自己包含查詢所需所有數據時，再也不訪問數據文件自己）。