James Day
Support Engineer, MySQL AB

I mean the UNION is a nice workaround but needs more code and logic where just writing a “WHERE col BETWEEN 19 AND 22″ is so much easier

If query with where clause “age=19 and zip in (…)” is executed what really is performed is sequence of lookups
age=19 and zip=const. Key length=4 is missleading in this case. It seems to be EXPLAIN bug in this case.

For query with “age between 19 and 22 and zip in (…)” what you have described is happening - index range lookup is performend on age condition and zip condition only checked after row is read.

You can use FLUSH STATUS; SHOW STATUS; and check Handler_XXX stats to see how query execution was performed.

Sorry to disturb you but I don’t quite understand the big performance difference between the “age=19″ query and the “age BETWEEN 18 AND 22 AND” query. According to the output of the EXPLAINs, I think the process of executing the “age=19″ query is:
1. Perform an index scan of KEY(age, zip), with scankey “age=19″. For key_len is 4, the condition on zip is useless in this step;
2. For each rows returned by the index scan above, retreive that row from the table and test where it’s zip is in (12345, 12346, 12347)
And I think the process of executing the “age BETWEEN 18 AND 22 AND” query is:
1. Perform an index range scan of KEY(age, zip), start with “age=18″ and end with “age=22″. For key_len is 4, the condition on zip is useless in this step;
2. For each rows returned by the index scan above, retreive that row from the table and test where it’s zip is in (12345, 12346, 12347)
So the main difference should be the first step. If the data has a uniform distribution, number of rows checked and returned by the first step of the “age=19″ query should be about 1/5 of the “age BETWEEN 18 AND 22 AND” qeury, so would be the total cost.

However, the difference of the real cost is much more tremendous. So chould you be so kind to give some more words about the reason of the performance difference?

This is not the case where index merge can apply:

mysql> explain SELECT SQL_NO_CACHE name FROM people WHERE age BETWEEN 18 AND 22 AND zip IN (12345,12346, 12347);
+—-+————-+——–+——-+—————+——+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——–+——-+—————+——+———+——+——+————-+
| 1 | SIMPLE | people | range | age,zip | zip | 3 | NULL | 19 | Using where |
+—-+————-+——–+——-+—————+——+———+——+——+————-+
1 row in set (0.00 sec)

As you see it can use only one of the indexes it selects to use zip as it is more selective;
As corelation between indexes is not known it is hard to tell what will be faster to use one of indexes only or
to intersect row pointers from both indexes.

If you would need OR in this case Index merge would apply.

mysql> explain SELECT SQL_NO_CACHE name FROM people WHERE age BETWEEN 18 AND 22 OR zip IN (12345,12346, 12347);
+—-+————-+——–+————-+—————+———+———+——+——-+—————————————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——–+————-+—————+———+———+——+——-+—————————————-+
| 1 | SIMPLE | people | index_merge | age,zip | age,zip | 1,3 | NULL | 38821 | Using sort_union(age,zip); Using where |
+—-+————-+——–+————-+—————+———+———+——+——-+—————————————-+
1 row in set (0.00 sec)

You’re right. This problem seems to be partially fixed and IN works for this case as well as union

mysql> explain SELECT name FROM people WHERE age in (18,19,20,21,22) AND zip IN (12345,12346, 12347);
+—-+————-+——–+——-+—————+——+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——–+——-+—————+——+———+——+——+————-+
| 1 | SIMPLE | people | range | age | age | 4 | NULL | 16 | Using where |
+—-+————-+——–+——-+—————+——+———+——+——+————-+
1 row in set (0.16 sec)

mysql> SELECT name FROM people WHERE age in (18,19,20,21,22) AND zip IN (12345,12346, 12347);
+———————————-+
| name |
+———————————-+
| ed4481336eb9adca222fd404fa15658e |
| 888ba838661aff00bbbce114a2a22423 |
+———————————-+
2 rows in set (0.05 sec)

I actually ment a bit different case but I thought I should simplify it which turned to be not the best way around.
I’ll post one more post in couple of days to show where union will be the only this which can help you