Question

I am reading tick value of the record with largest id. What is the difference between following queries that causes to slow execution?

Slow Query:

SELECT tick
FROM   eventlog
WHERE  id IN (SELECT max(id) FROM eventlog)

Quick Query:

SELECT max(id) INTO @id
FROM   eventlog;

SELECT tick
FROM   eventlog
WHERE  id = @id;

Schema

CREATE TABLE eventlog (
    id INT (11) NOT NULL AUTO_INCREMENT,
    tick INT NOT NULL,
    eventType_id INT NOT NULL,
    compType INT (10) UNSIGNED NOT NULL,
    compID INT (10) UNSIGNED NOT NULL,
    value_double DOUBLE NOT NULL,
    value_int INT (10),
    hierarchy_id VARCHAR (255) NOT NULL,
    PRIMARY KEY (id),
    INDEX htet (
        hierarchy_id,
        tick,
        eventType_id
    )
)

Answer 1

Because the in query doesn’t use index, the mysql will scan all the records to find the row.

From http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

B-Tree Index Characteristics

A B-tree index can be used for column comparisons in expressions that
use the =, >, >=, <, <=, or BETWEEN operators.

There’s no IN

And

Hash Index Characteristics

Hash indexes have somewhat different characteristics from those just discussed:

They are used only for equality comparisons that use the = or <=>
operators (but are very fast). They are not used for comparison
operators such as < that find a range of values.

there’s no IN either.

As @tombom mentioned, foo IN ('bar', 'bla') is short for foo = 'bar' OR foo = 'bla', however, I believe they’re different. So I make a test on a table with enough data records, and find out the following:

mysql> show columns from t_key;   
+-------+---------+------+-----+---------+----------------+
| Field | Type    | Null | Key | Default | Extra          |
+-------+---------+------+-----+---------+----------------+
| a     | int(11) | NO   | PRI | NULL    | auto_increment |
| b     | int(11) | YES  | MUL | NULL    |                |
+-------+---------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> select count(a) from t_key;
+----------+
| count(a) |
+----------+
|   989901 |
+----------+
1 row in set (0.00 sec)

mysql> explain select a from t_key where a in (select max(a) from t_key);  
+----+--------------------+-------+-------+---------------+---------+---------+------+--------+------------------------------+
| id | select_type        | table | type  | possible_keys | key     | key_len | ref  | rows   | Extra                        |
+----+--------------------+-------+-------+---------------+---------+---------+------+--------+------------------------------+
|  1 | PRIMARY            | t_key | index | NULL          | PRIMARY | 4       | NULL | 989901 | Using where; Using index     |
|  2 | DEPENDENT SUBQUERY | NULL  | NULL  | NULL          | NULL    | NULL    | NULL |   NULL | Select tables optimized away |
+----+--------------------+-------+-------+---------------+---------+---------+------+--------+------------------------------+
2 rows in set (0.00 sec)

mysql> explain select a from t_key where a =(select max(a) from t_key);
+----+-------------+-------+-------+---------------+---------+---------+-------+------+------------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra                        |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+------------------------------+
|  1 | PRIMARY     | t_key | const | PRIMARY       | PRIMARY | 4       | const |    1 | Using index                  |
|  2 | SUBQUERY    | NULL  | NULL  | NULL          | NULL    | NULL    | NULL  | NULL | Select tables optimized away |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+------------------------------+
2 rows in set (0.00 sec)

Then I try the IN query with static sequences, it works as @tombom mentioned:

mysql> explain select a from t_key where a in (100,200);
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | t_key | range | PRIMARY       | PRIMARY | 4       | NULL |    2 | Using where; Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
1 row in set (0.00 sec)

mysql> explain select a from t_key where a=100 or a=200;
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | t_key | range | PRIMARY       | PRIMARY | 4       | NULL |    2 | Using where; Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
1 row in set (0.00 sec)

I don’t know whether the mysql would convert the IN query into ORs one when possible(for instance, the sequences is known before query), and I didn’t find related documents, but the explain shows that it did scan the table in this situation.