Оптимизация поискового запроса!

makcumyc

Новичок
Оптимизация поискового запроса!

Всем привет!
Возникла проблема с оптимизацией. Есть запрос:
[query] =>
PHP:
select count(p.products_model)  
from  products p , shop_cat c , shop s  
where s.id=c.shop_id and c.id=p.shop_cat_id and p.products_price>0 and   
MATCH(txt) AGAINST('Moulinex*' IN BOOLEAN MODE )  and  
MATCH(txt) AGAINST('BKA347*' IN BOOLEAN MODE )
[time] => 0.611722946167

На который уходит от 0.005 до >25 секунд. Не могу разобраться, почему такие скачки и что с этим делать.
Думал проблема в том, что используются 3 таблицы, но хотя, когда я делал такой запрос:
[query ]
PHP:
select product_id  
from  products  
where  
MATCH(txt) AGAINST('Moulinex*' IN BOOLEAN MODE )  and   
MATCH(txt) AGAINST('BKA347*' IN BOOLEAN MODE )
Результат был примерно такой же - то запрос проходил быстро, то затягивался более чем на 25 секунд, пробовал соединить MATCH запрос в 1, а не как сейчас - 2, но это тоже не помогает .
У самого поля “TXT” index FULLTEXT. Товаров > 1 миллиона. Подскажите как оптимизировать запрос. Одно время предлагалось поставить Сфинкс, но возможно ли как-то без него обойтись, ведь mysql, я думаю, спокойно может обрабатывать данные больше миллиона. Может как-то разбить данные на партиции? Хотя я тоже пытался это сделать, но не к чему путному это не привело. Поле “TXT” имеет примерно такие данные внутри:

######################
1) “Nokia 3310”
2) “Apple Iphone 3G”
3) “Apple Iphone 3G 8G”
4) “Apple Iphone 3G 16G”
5) “Nokia 12345”
N) …
######################

и если я в поиске вобью “Appl Iphon” – я должен получить, что по такому запросу найдены 2-ой, 3-ий, 4-ый вариант записей. Подскажите, как быть с оптимизацией?
 

Wicked

Новичок
какой статус у этого запроса в SHOW PROCESSLIST, когда он долго выполняется?
 

makcumyc

Новичок
посмотрел SHOW PROCESSLIST:
в некоторых случаях

State - Sending data
Info - select count(p.products_model) from products p...

но часто, когда делаю запрос и смотрю SHOW FULL PROCESSLIST там нету никаких новых запросов select count(p.products_model) from products p...

как эти данные могут помочь?

-~{}~ 09.10.08 09:59:

Люди, неужели никто не сталкивался с такой проблемой ?
 

makcumyc

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

сам запрос то правильно сделан?!
 

Gas

может по одной?
ну обычно такие тупняки бывают когда индексы не в памяти ещё и много других IO операций в системе.

Но кинь explain что-ли, поглядим.
Вот человек задавал подобный вопрос - http://www.sql.ru/forum/actualthread.aspx?tid=405071, тоже можешь попробовать создать отдельный индексный блок для этой таблицы и в него загрузить индексы, может лучше станет.

А у тебя сортировка результатов есть? Если да, то скорее всего она идёт не по идексу и при условии fulltext + отдельный btree индекс - будет читаться так-же datafile. Попробуй вместо 2-х запросов (подсчёт количества и получение порции результатов) сделать один с SQL_CALC_FOUND_ROWS. И я бы все слова искал в одном AGAINST'е.

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

Sych

Новичок
Самая правильная оптимизация такого запроса - вообще его не использовать а для поиска при таких объемах использовать Sphinx
 
Сверху