[MySQL] Медленный join по миллиарду записей

С помощью сфинкса получаете нужные АйДишники лайком?

Ну типа SELECT id FROM FULL where name like '%колеса%'

Сколько у сфинкса уходит на выборку?

Что если попробывать без сфинкса? Чтобы сразу была выборка имя и запись в файл.

Ну и попробуйте сделать дефрагментацию жесткого диска. Это должно помочь немного/много(в зависимости от текущего состояния винта).

Еще можно попробовать перенести базу на жесткий диск размером скажем 100ГБ, чтобы было место в запасе, но и чтобы его было не сильно много(то есть если по диску фрагменты раскиданы, то хотя бы не сильно далеко друг от друга)

нет, обычным запросом через api сфинкса по его индексу.

15 секунд

пробовал, медленнее работает, пробовал Fulltext без морфологии и пробовал tsearch fts в Postgresql

Спасибо, попробую сейчас дефрагментацию.

А вообще прирост при использовании SSD большой будет? Или не более 2-3 раза?

Первое, что нашел в поиске:)

Заказал SSD, перенесу туда БД. Надеюсь что прирост в скорости будет раз в 10. Если во время выполнения запроса смотреть скорость чтения с винчестера, процесс mysql считывает со скоростью 1.2МБайта. Значит на SSD скорость должна быть около 25-30Мбайт, это даже в 20 раз быстрее. Посмотрим что получится в итоге :)

Всем спасибо.

Если у кого есть идеи по оптимизации запроса или тюнингу конфига MySQL, буду очень благодарен.

Сколько временная таблица весит? Он ее на жесткий не сваливает, только в оперативке хранится?

Дайте мускулу всю оперативку, которую возможно.

Все же задачу надо пересмотреть и пути её решения.

Сфинкс - очень быстрый поисковый двиг.

ssd - поможет, но не сильно.

конфиг менять, весь кеш - в память переносить.

А поле Name из сфинкса получать не вариант? Зачем MySQL дёргать?

Милованов Ю.С, немного совсем, 40мб. Как определить сваливает он на винчестер или нет не знаю, но тип базы Memory, таблица должна в оперативную память грузиться поидее. Но скорее всего это не влияет на скорость запроса, ведь главная база FULL, с которой джойнится временная, находится на винчестере.

Я вот чего не понимаю: почему в EXPLAIN запроса не показано что используется Primary Key во временной таблице tmp?

ivan-lev, пробовал указывать поле name как аттрибут в сфинксе. Но столкнулся с множеством проблем. Сфинкс не может делать индексы с атрибутами размером более 4Гб, приходилось базу делить на несколько частей по 4Гб и делать каждой индекс. Ещё проблема - не хватает памяти для всех индексов. Дело в том, что индекс с аттрибутом грузится в память, а размер индексов выходит 50гб, т.е. нужно 50гб памяти для сфинкс, либо создавать 5 конфигураций сфинкса и подгружать индексы по отдельности что совсем неудобно. Либо собирать новый ПК с 64гб памяти.

TF-Studio, почему SSD поможет не сильно? По моим прикидкам прирост в скорости должен быть раз так в 10-20. Вам ведь SSD помог? Или у вас была иная задача? Выборки значительно ускорились?

Зависит от данных. На некоторых операциях у нас после переноса на ssd в 100 раз скорость увеличилась. На некоторых всего в 2-3. Заказывайте ssd раза в 2 больше объемом чем Ваша БД (от объема у ссд и кол-ва свободного места на нем скорость зависит).

Конфиг мускула крутить Вам бесполезно, т.к. объем данных такой, что в кэш это не поместится, тут все равно чистое считывание будет.

По оптимизации запроса - все что можно уже выше сказано.

А вот по оптимизации решения задачи - возможно что-то и можно придумать. Что конкретно собственно Вы делаете? 2 миллиарда записей по 70 буков - что это за данные (полутвиттер какой-то?) и что именно Вы по ним ищите (строки, буквы, числа?)? Какого типа поисковые запросы идут (фултекст, по вхождению, по вхождению с начала строки)? И т.д.?

Это как раз намекает на то, что SSD Вам вообще не поможет, 1.2 мегабайта в секунду это значит что у Вас узкое место совсем не в диске, нагрузки на дисковую систему нет вообще...

Есть конечно вариант с совсем АДОВОЙ дефрагментацией... но это ОЧЕНЬ вряд-ли...

Добавьте в конфиг join_buffer_size