Mysql used key changes between two consecutive EXPLAINs I have a huge unmaintained innodb table (~1.5billion rows), I just started to try to query it. I write &amp;&amp; instead of AND once; and surprise! it uses different key!

 EXPLAIN EXTENDED SELECT * FROM trans_cache WHERE duration = 0 AND status =-7;
+----+-------------+-----------+------+------------------------------+-----------+---------+-------+-----------+----------+-------------+
| id | select_type | table     | type | possible_keys                | key       | key_len | ref   | rows      | filtered | Extra       |
+----+-------------+-----------+------+------------------------------+-----------+---------+-------+-----------+----------+-------------+
|  1 | SIMPLE      | trans_cache | ref  | duration_status,status | status | 2       | const | 219050284 |   100.00 | Using where |
+----+-------------+-----------+------+------------------------------+-----------+---------+-------+-----------+----------+-------------+


And

EXPLAIN EXTENDED SELECT * FROM trans_cache WHERE duration = 0 &amp;&amp; status =-7;
+----+-------------+-----------+------+------------------------------+--------------------+---------+-------------+-----------+----------+-------------+
| id | select_type | table     | type | possible_keys                | key                | key_len | ref         | rows      | filtered | Extra       |
+----+-------------+-----------+------+------------------------------+--------------------+---------+-------------+-----------+----------+-------------+
|  1 | SIMPLE      | trans_cache | ref  | duration_status,status | duration_status | 4       | const,const | 214672958 |   100.00 | Using where |
+----+-------------+-----------+------+------------------------------+------------------+---------+-------------+-----------+----------+-------------+


And since they are different, which query should be faster?

EDIT I found that it is doesn't depend on AND or &amp;&amp;. The used key changes randomly in EXPLAIN results.
It sounds like the table is on the cusp of a cutover for the query optimizer between the estimated total rows and estimated rows being looked up.

The use/ignore index syntax exists for situations like this.

The pitfall to this approach is when the table dynamics change in the future such that it's really not the best choice.