Помогите оптимизировать запрос MySQL

Trol, быстрее PK ничего вам не предложат.

Покажите, мы тоже посмотрим.

Уже "хорошо".. в MyISAM блокировки на уровне таблиц. Данные в таблице изменяются часто?

Если ограничиться двумя значениями WHERE id in (1,2)?

Если подсунуть Force index (`id`) ?

p.s. А точно нужны 30к ID-шников?

IDшники каждый раз в запросе меняются, или они всегда одни и те же(ну например для категории "запчасти для (А)КПП").

Если они фиксированы, то думаю имеет смысл закэшировать запрос, чтобы выполнить его 1 раз, а уже потом просто брать данные из кэша. Если данные меняются периодически, то сделать так, чтобы после замены кэш-запроса обновлялся.

А вообще, если в таблице хранятся все запчасти, то думаю имеет смысл разбить на категории(двигатель(система распределения топлива, ГБЦ), коробка, подвеска).

PS. MyISAM и 1милиард записей, как по мне - кощунство. Особенно если СЕЛЕКТы чаще ИНСЕРТов.

PPS. Вы скажите не что Вы делаете, а что хотите получить(какую цель преследуете). Может есть абсолютно другой подход, но мы об этом и подумать не можем, так как обладаем небольшим кол-вом информации.

Вот Explain по другой таблице, структура таже, индексы теже, только запрос сделал на 167 ID чтобы долго не ждать, запрос выполнился за 0,05сек, но индекс не используется:

ivan-lev, да, нужно вытащить данные по всем 30к ID. Force Index и Use Index не помогают, explain показывает что индекс не используется. Данные в таблице не изменяются, нужно только выборку по ней делать.

Милованов Ю.С, нужно сделать быстрый полнотекстовый поиск. Пробовал Fulltext, но тоже долго ищет. Вот перешёл на Sphinx, но он выдаёт только ID нужных мне записей и приходится делать запрос в БД MySQL для выборки нужных полей с этими ID.

К Sphinx притензий нет, ID выводятся достаточно быстро (секунд 5-10) но вот выборка по этим ID из MySQL очень долгая.

А как в INT поместилось 13 знаков? Должно быть BIGINT ...

Разбить avtozapchasti на avtozapchasti_mazda, avtozapchasti_tazik и т.д., очень сложно?

В INT максимальное значение 4294967295 (10 знаков ), об этом не знал, но всёравно, если поле описано как INT(13), это ведь не должно быть причиной такого медленного поиска. В INT 1 миллиард записей поместился.

Смысла нет, иначе придётся искать потом по каждой таблице.

Откуда взяли 13 знаков?

INT UnSigned: от 0 до (2^32)-1, то есть до 4.294.967.295

ТС, таблица уж сильно большая для мускула. Не говорю что с ней невозможно работать, но желательно разбить на несколько таблиц. Чем меньше записей в таблице - тем лучше, но без фанатизма:)

Ну и прекрасно. Делаете СЕЛЕКТ на странице с пунктами "ВАЗ", "ТАЗ", "ГАЗ", "*АЗ" и т.д.

В зависимости от выбранного пункта ищем по определенной таблице. Просто нет смысла держать такую большую БД, если данные из нее можно сгрупировать и разложить на несколько таблиц.

Первый пост ТС.

INT - 10 знаков, при первых 42.... Остальное срежет и промолчит :)

Увидел, что было выше.

Настройки source сфинкса можете показать?

Для конкретного поиска.

Кстати, очень может быть, что множество одиночных селектов выполнится намного быстрее, чем один но большой.

Зачем запчасти для мазды искать в других марках?