Nail

У InnoDB есть свой справочник таблиц, который оно держит в памяти. Там содержится инфа обо всех открывавшихся таблицах, в стандартной версии MySQL он никогда не очищается — отсюда рост памяти.

В Percona xtradb против этого добавили настройку innodb_dict_size_limit
www.percona.com/doc/percona-server/5.5/management/innodb_dict_size_limit.html

Once a table is opened, it is never removed from the data dictionary unless you drop the table or you restart the server. In some cases, the data dictionary grows extremely large. If this consumes enough memory, the server will begin to use virtual memory. Use of virtual memory can cause swapping, and swapping can cause severe performance degradation. By providing a way to set an upper limit to the amount of memory the data dictionary can occupy, this feature provides users a way to create a more predictable and controllable situation.

Тут примеры приводят какие-то удивляющие, я решил проверить.

Версия 5.5.25a-27.1-log Percona Server
В таблице 26 миллионов строк, размер на диске 4.5G.

FLUSH STATUS; select * from table where id in (1000,100000,1000000,3000000,5000000,7000000,10000000); SHOW SESSION STATUS LIKE 'Handler_read%'; 

+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Handler_read_first    | 0     |
| Handler_read_key      | 7     |
| Handler_read_last     | 0     |
| Handler_read_next     | 0     |
| Handler_read_prev     | 0     |
| Handler_read_rnd      | 0     |
| Handler_read_rnd_next | 0     |
+-----------------------+-------+
7 rows in set (0.00 sec)

FLUSH STATUS; select * from table where id in (1000,100000,1000000,3000000,5000000,7000000,10000000) limit 4; SHOW SESSION STATUS LIKE 'Handler_read%'; 

+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Handler_read_first    | 0     |
| Handler_read_key      | 4     |
| Handler_read_last     | 0     |
| Handler_read_next     | 0     |
| Handler_read_prev     | 0     |
| Handler_read_rnd      | 0     |
| Handler_read_rnd_next | 0     |
+-----------------------+-------+
7 rows in set (0.00 sec)

Сами запросы выполняются за 0.00 sec

Вывод:
Проверяйте индексы и статистику, апгрейдьте mysql.

Avoid using IN(...) when selecting on indexed fields
Я думаю это только для составных индексов: fields — во множественном числе.

Подробнее описано здесь:
www.mysqldiary.com/optimizing-the-mysql-in-comparison-operations-which-include-the-indexed-field/

Если делать ID IN (...) — ничего плохого в этом нет.