1. В MySQL в оператор IN список какой мксимальной длины можно втюхать ?
Скажем, в списке будут числа от 1 и далее. И таких чисел будет 1000. Справится ? А если 1 000 000 ?

2. Использует ли MySQL индексацию IN-списка перед выполнением запроса ?
Ведь в противном случае ему придётся для каждой записи последовательно сравнивать некоторое значение с каждым значением из списка. А в случае с индексацией на каждой записи он будет сразу искать по индексу. Наверняка индексирует, но на всякий уточнить не мешает.

автор1) Насколько я помню, лимитирует только max_allowed_packet.
Из справки :
автор The maximum size of one packet or any generated/intermediate string.

The packet message buffer is initialized to net_buffer_length bytes, but can grow up to max_allowed_packet bytes when needed. This value by default is small, to catch large (possibly incorrect) packets.

You must increase this value if you are using large BLOB columns or long strings. It should be as big as the largest BLOB you want to use. The protocol limit for max_allowed_packet is 1GB. The value should be a multiple of 1024; nonmultiples are rounded down to the nearest multiple.

When you change the message buffer size by changing the value of the max_allowed_packet variable, you should also change the buffer size on the client side if your client program permits it. The default max_allowed_packet value built in to the client library is 1GB, but individual client programs might override this. For example, mysql and mysqldump have defaults of 16MB and 24MB, respectively. They also enable you to change the client-side value by setting max_allowed_packet on the command line or in an option file.

The session value of this variable is read only.
...
Так строка после IN относится к этому самому "packet or any generated/intermediate string" ?

автор2) Строит бинарное дерево из списка.
Тогда скорость выполнения оператора IN на каждой записи расти будет очень медленно по сравнению с ростом числа элементов в списке. Скажем, при увеличении числа элементов в списке на 3 порядка (например, с 1000 до 1000 000) удельная скорость уменьшится на 1 порядок. Вроде, так.

авторХотя общее время выполнения запроса будет расти намного быстрее. Например, расходы на парсинг будут расти линейно.
Так парсинг будет выполняться только 1 раз для всего запроса.
Скажем, в запросе нужно для 10 000 000 записей проверить вхождение (IN) в список из 1 000 000 чисел. Время, затрачиваемое на парсинг каждого дополнительного числа в IN-списке, гораздо меньше времени, затрачиваемого на выпоkнение оператора IN для одной записи (или не так ?). В итоге только лишь при удвоении длины IN-списка при фиксированном числе записей время выполнения запроса вырастет не более чем в я раза. Так или нет ? если прикинуть ?

2 варианта:
1) 10 000 000 записей и IN-список из 1 000 000 чисел
2) 10 000 000 записей и IN-список из 2 000 000 чисел
Во втором случае примерно во сколько раз увеличится время выполнения запроса, если принимать во внимание только длину списка ? Т.е. считаем, что скорость прохода дерева (выполнения оператора IN) не меняется.

Вот ещё кое-что по сабжу. А именно - замеры скорости выполнения запросов с IN:
http://habrahabr.ru/qa/22419/#answer_91895

Результаты очень неплохие.