2、怎麼利用index extensions

事實上，輔助索引實際也儲存主鍵值的特性，在InnoDB引擎中一直都是如此，只是從5.6.9版本開始後，在計算執行計劃時，查詢最佳化器（optimizer）才能識別到這個特性，並且利用這個特性。而在5.6.9以前，雖然這個特性也存在，但並不被查詢最佳化器識別，也就無法被利用了。

這個特性可適用於 ref, range, and index_merge 等多種索引訪問方式，在稀鬆索引掃描（loose index scan）、聯接（join）、排序以及MIN()/MAX()等場景下。

我們來看看這個特性怎麼被最佳化器識別並利用的，假設上述測試表中的測試資料有：
SELECT * FROM t;
+—-+—-+—-+—-+
| a | b | c | d |
+—-+—-+—-+—-+
| 1 | 2 | 4 | 2 |
| 1 | 3 | 2 | 2 |
| 1 | 4 | 9 | 2 |
| 1 | 5 | 9 | 2 |
| 1 | 6 | 8 | 2 |
| 2 | 2 | 9 | 2 |
| 3 | 2 | 8 | 2 |
| 4 | 2 | 6 | 2 |
| 5 | 2 | 6 | 2 |
| 6 | 2 | 1 | 2 |
+—-+—-+—-+—-+

MySQL版本：5.6.21-70.0-log Percona Server (GPL), Release 70.0, Revision 688。

假設有下面的查詢，看下它的執行計劃：
mysql> explain select a,b,c FROM tr force index(i_c) WHERE a = 1 AND c = 4;
+----+-------------+-------+------+---------------+------+---------+-------------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref         | rows | Extra       |
+----+-------------+-------+------+---------------+------+---------+-------------+------+-------------+
|  1 | SIMPLE      | tr    | ref  | i_c           | i_c  | 8       | const,const |    1 | Using index |
+----+-------------+-------+------+---------------+------+---------+-------------+------+-------------+
1 row in set (0.00 sec)

在5.6.9以前的版本（或者修改最佳化器開關，關閉 index extensions 特性。如果用5.6.9以後的版本測試，還請記得）：
可執行下面的命令關閉 index extensions 特性：
mysql> SET optimizer_switch ='use_index_extensions=off';     
Query OK, 0 rows affected (0.00 sec)


mysql> explain select a,b,c FROM tr force index(i_c) WHERE a = 1 AND c = 4;
+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra                    |
+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | tr    | ref  | i_c           | i_c  | 4       | const |    2 | Using where; Using index |
+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+
1 row in set (0.00 sec)

這兩個執行計劃的區別在於：

• 前者的key_len是8而後者是4，預示著可以用到的索引不僅是i_c這個索引，還有主鍵索引；

• 前者的ref列值是const,const，而後者只有const，預示著前者用到了2個索引部分，而後者只有一個；

• 前者評估的rows為2，而後者評估的rows為3，因為前者效率更高；

• 後者的Extra列中多了Using Where，表示後者還需要從結果中再次過濾資料，而不能像前者那樣直接利用索引取得結果。

我們還可以根據觀察STATUS中的Handler_read_%值差異來對比兩個SQL的實際執行代價（執行FLUSH STATUS後，執行查詢SQL，再執行SHOW STATUS LIKE ‘Handler_read_%’ 檢視）：

• 後者的代價是 Handler_read_next = 3；

• 前者的代價是 Handler_read_next = 2；

• 如果資料量更大的話，這個差值也會隨之增大。

由此可見，前者的效率確實要比後者來的更高。

3、後記

我們應該經常關注新版本的新特性，利用這些新特性提升SQL效率 ：）