тормоза fulltext поиска

[esergey]

тормоза fulltext поиска

Пару дней ковырял, так и не понял что происходит. Помогите плиз, кто в курсе.

Есть большая база данных, порядка 200 000 записей (55 mb) с fulltext индексом.

Делаю к ней запрос:
SELECT SQL_NO_CACHE SQL_CALC_FOUND_ROWS * from table WHERE MATCH(name) AGAINST('$search1') limit ".$begrow.",20

Дальше ситуация следующая. При первом вызове скорость работы зависит от SQL_CALC_FOUND_ROWS. Если порядка 3000 то запрос выполняется около 20 сек. Повторный такой же запрос или с измененными параметрами limit выполняется очень быстро. Предположил что кэшируется запрос и включил SQL_NO_CACHE. Но ситуация такая же.

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

 

[Sad Spirit]

Автор оригинала: esergey
Хотелось бы выяснить где же все таки инфа кэшируется?

Таки в памяти. Кэширует же не только мыскль результаты запроса, но и тот же мыскль данные таблиц и индексов, а также не стоит забывать про файловый кэш ОС.

И возможно ли ускорить быстродействие первого запуска запроса?

Да, поставив диски побыстрее. Или купить модный новый SSD, бгыгыгы.

 

[esergey]

Логика подсказывает что тормозит сортировка MATCH(name) AGAINST('$search1') по релевантности. Чем больше данных выберется, тем медленнее запрос. Эти отсортированные данные как то и кэшируются. Чисто из любопытства хотелось бы узнать как.

Вопрос следующий. Многие тут расхваливают быстродействие fulltext поиска. Хотелось бы узнать где я все таки проезжаю. Таблица большая, но похоже это на скорость не влияет. На скорость влияет количество всех найденых результатов. Если найдено 100 записей - очень быстро, 1000 - 5 секунд, 3000 - 20 секунд.
Подскажите как можно в fulltext уменьшить количество найденных результатов? И реально fulltext быстро работает или это все сказки?

 

[donflash]

Re: тормоза fulltext поиска

Может быть причина в этом?
http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

 

[esergey]

Спасибо, donflash. Проблема действительно в этом. А я грешил совсем на другое.

 

[donflash]

Да пожалуйста, сам с полгода назад столкнулся с тормозами SQL_CALC_FOUND_ROWS

 

[esergey]

Добавить хотел, для тех кому интересно. Продолжил тестирование. Использование count как описано в статье прироста производительности не дает. Когда использую count выхожу на те же 20 секунд. По крайней мере знаю где ковырять теперь.

Соответственно и вопрос. Попробовал "SELECT count(*) from books WHERE MATCH(name) AGAINST('$search2') limit 0,100" В надежде что выдаст количество результатов от 0 до 100, но выдает гораздо больше. Кто нибудь подскажет как мне получить количество записей чтобы оно было не больше 100 например. Ограничить поиск для быстродействия.

 

[Активист]

А зачем тебе вообще count(*) ?

Если он тормазит - не используй.

Скажем, тебе нужно вытащить результаты поиска. Пожалуйста.
Выводишь по-страничнл=о (20 на странице).
Ставишь ссылку далее. Если на странице результата < 20 - то не выводишь ссылку далее.

 

[esergey]

Кому интересно count(name) - name - индекс, работает в разы быстрее чем count(*)

Активист, спасибо за подсказку, как то самому в голову не пришло. Наверно этим путем и придется идти.

 

[Angerslave]

Эх, есть замечательная книга High Performance MySQL от O'Rielly, там очень хорошо написано про поиск слабых мест и оптимизацию запросов. Думаю, любому, кто работает с MySQL, будет полезно почитать.

 

[Активист]

esergey
> Кому интересно count(name) - name - индекс, работает в разы
> быстрее чем count(*).

Это естественно.

-~{}~ 22.01.09 23:17:

esergey
Есть еще вариант - создать таблицу, в нее вставлять поисковый запрос и количество найденных результатов. При поиске брать количество из той таблицы.

Чистить раз в N.