MySQL, огромная таблица, ускорение выбрки

Ну понятно, "IN" - поиск по большому неупорядоченному условию ему не нравится.

Попробуйте вариант /ru/forum/comment/13525993 - вполне возможно, что это решит проблему.

Ladycharm

В blob у меня хранится строка, длинною в 256 символов (вернее, цифр) и ужатая COMPRESS(). Если буду хранить ее несжатой, то таблица увеличится в 2,5 раза.

Разнести все по разным таблицам - это светлая идея, на мой взгляд.

Только 2.5 млн записей - это легкий тест. В продакшен будет намного больше. Если дойдет до этого... Так что хочу сделать все, чтобы максимально оптимизировать все.

Ещё раз - вы ищите по большому, неупорядоченному списку. Естественно, это тормозит.

Достаточно здравое решение - предварительно записать этот список в таблицу с индексами и сделать выборку через INNER JOIN.

dlyanachalas

Признаться, но могу врубится в этот алгоритм (или же он мне не подходит).

Наборы ID, входящие в IN (....) моего SELECT-запроса никогда не повторяются! Зачем мне хранить эти наборы?

Если я не прав, объясните в двух словах как это работает? Или такую таблицу нужно налету создавать, чтобы избавится от IN в запросе, а потом ее очищать?

Если что, я не привязан к MySQL. Может тут лучше подойдет какая-то другая технология?

Хранить не надо, создаете и удаляете каждый раз для каждого запроса.

Да, так. А работает за счет того, что так вы столько раз индексы дергаете, сколько у вас параметров в IN. При временной таблице, будете дергать их 1 раз.

Причем тут MySQL. Это реляционная алгебра. Неплохо изучить перед работой со сложными данными ;) А то все думают, что если что, "отделаются настройкой кэша" :)

Похоже, dlyanachalas прав на счёт "IN" - поиск по большому неупорядоченному условию". Проверить - легко, поменяйте условие в запросе

на

Тогда будет задействован индекс по id. Генерить строку с OR id= можно так же автоматически, если ваши id - в массиве $arr:

"WHERE id=".imlpode(" OR id=", $arr)

PS: А на счйт полей BLOB - 2 месяца назад решала аналогичную проблему с таблицей на 500 000 записей: у меня были поля ТEXT(по сути - те же BLOB, MySQL резервирует под них место большого размера, похоже, даже под пустые). А потом в этом огромном файле очень долго ищет даже по другим индексным полям, причём TEXT - даже не выбирались при SELECT. Вынесла их в другую таблицу и связала по ID - всё стало летать.

Ещё раз - вы ищите по большому, неупорядоченному списку. Естественно, это тормозит.



Достаточно здравое решение - предварительно записать этот список в таблицу с индексами и сделать выборку через INNER JOIN.

Тормозит даже на небольшом списке. 50 записей по их id берутся за секунду.

Сделал я эту таблицу со временной связкой... И ничего. Ровно то же самое время.

Проверить - легко, поменяйте условие в запросе 

Проверил. Время выборки такое же как и раньше.

Огромное спасибо за помощь всем!

Индекс во временной таблице не забыли?

На всякий случай, я бы так делал:

INSERT INTO selections (id) values (4144), (5255), (6656), (9695);

SELECT compkey3_all.* FROM compkey3_all INNER JOIN selections ON compkey3_all.id=selections.id;

TRUNCATE TABLE selections;

А selections - просто с одним столбцом id (Primary Key).

---------- Добавлено 24.02.2015 в 03:45 ----------

Кажется, вы не поняли. Неупорядоченный список - это условие в вашем IN.

Не забыл. Связанный из 2 столбцов.

Но ведь даже "список" с 1 id выполняется медленно - 0,2 сек.

kalim, вам уже сказали в чем ваша проблема - локалхост. Переведите тесты на рабочий сервер и тогда можно будет говорить.