MySQL未按预期使用索引

Question

EXPLAIN on this query

select v.type,sum(c.rank)
from
  (select distinct power,color,type from vehicle) v
  join configuration c using (power,color)
group by v.type

gives

+----+-------------+---------------+------------+-------+---------------+-------------+---------+-----------------------------------------+---------+----------+---------------------------------+
| id | select_type |     table     | partitions | type  | possible_keys |     key     | key_len |                   ref                   |  rows   | filtered |              Extra              |
+----+-------------+---------------+------------+-------+---------------+-------------+---------+-----------------------------------------+---------+----------+---------------------------------+
|  1 | PRIMARY     | configuration | NULL       | ALL   | veh           | NULL        | NULL    | NULL                                    |   76658 |   100.00 | Using temporary; Using filesort |
|  1 | PRIMARY     | <derived2>    | NULL       | ref   | <auto_key0>   | <auto_key0> | 6       | configuration.power,configuration.color |      65 |   100.00 | NULL                            |
|  2 | DERIVED     | vehicle       | NULL       | index | cov           | cov         | 20      | NULL                                    | 5058658 |   100.00 | Using index                     |
+----+-------------+---------------+------------+-------+---------------+-------------+---------+-----------------------------------------+---------+----------+---------------------------------+

The index on configuration (power,color) is not used even if I set force index

If I use a table instead of a subquery

create table tmp select distinct power,color,type from vehicle

then Explain on the 'same' query

select v.type,sum(c.rank)
from
  tmp v 
  join configuration c using (power,color)
group by type

becomes

+----+-------------+---------------+------------+------+---------------+------+---------+---------------------+---------+----------+---------------------------------+
| id | select_type |     table     | partitions | type | possible_keys | key  | key_len |         ref         |  rows   | filtered |              Extra              |
+----+-------------+---------------+------------+------+---------------+------+---------+---------------------+---------+----------+---------------------------------+
|  1 | SIMPLE      | tmp           | NULL       | ALL  | NULL          | NULL | NULL    | NULL                | 1016144 |   100.00 | Using temporary; Using filesort |
|  1 | SIMPLE      | configuration | NULL       | ref  | veh           | veh  | 6       | tmp.power,tmp.color |       2 |   100.00 | NULL                            |
+----+-------------+---------------+------------+------+---------------+------+---------+---------------------+---------+----------+---------------------------------+

and this is 4 times faster

How can I avoid using a hard table ?

Answer 1

In the first case the optimizer thinks it is better to do it the other way around, by using the auto generated key in the derived table.

In the second case there is no key in the temp table, so the best plan is to go for tmp first.

You should be able to force the table order by using STRAIGHT_JOIN instead of JOIN .