Георгий Виноградов

вы батенька тогда не разработчик, вы "крутой хакер" постсоветского менталитета ─ кстати принтеры чините ?

я принципиально отказываюсь тратить силы на изучение чужого кода или на описания того как работает моя программа

что значит отказываюсь писать документацию ? а кто ее тогда напишет?
да это время, тоесть должно быть оплачено
вы настока круты и известны что ради вас перепишут весь проект ?
нормальный код чаще читается чем пишется.
нормальный разработчик пишет доку в первую очередь для себя
я бы с таким неадекватом отказался работать

Просто берете книжку "Основы баз данных" и читаете, сразу все прояснится. Задавши этот вопрос вы сразу говорите, что вообще не понимаете что такое реляционные базы данных и как с ними работать, и пытаетесь одним вопросом на тостере познать дзен. Сначала читайте - потом спрашивайте то, чего не поняли.

Как то просили сделать сокращалку. Вторая часть ссылки была просто представление ID в 62 — ричной системе.

Вообще, запросы крайне сложно оптимизировать не имея перед глазами вообще ничего.
Покажите create table, explain extended… Ну да ладно, поворчали, и будет.

Если вы используете простые числовые значения в IN и сам запрос простой, как пуля, например

select * from test1 where ID in (1,2,5,3);

То можно оставить как есть. На сколько я в курсе, мускуль будет всяко сам сортировать этот список, чтобы потом по нему искать. И даже индексы для этого будет использовать.

Если запросы сложнее (join, order by, union), то вас ждет печаль, а нас — более подробное описание задачи. Зачастую быстрее загрузить все ID во временную таблицу, и потом уже с ней работать. Чем ждать пока запрос с заменой обычного условия на IN отработает.