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效率 ：）