GororПрограмёр Не все LIKE запросы используют индексы.
Это да, но я специально их эксплейн запросами проверял, чтоб все они использвоали индексы..
Вот один из основных запросов:
1.
2.
3.
4.
5.
6.
7.
SELECT sl.id, sl.content, sb.key_id, sb.site_id, sb.page_id, sb.rate, sb.content_2, sb.img_url, ud.id, ud.img_par_1, ud.url, ud.par_1
FROM search_live sl
LEFT JOIN search_base sb ON sl.id = sb.key_id
LEFT JOIN url_db ud ON sb.site_id = ud.id
WHERE sl.id=$key OR sb.key_id=$key OR sb.key_id=$parent OR sl.id=$parent OR sl.content
LIKE '$q%'
ORDER by sb.rate DESC
Ну и при каком количестве записей на выходе начинает тормозить? (я имею ввиду сколько записей должно попасть в выборку, что бы начались тормоза?)
1. Один из JOIN может неверно подобрать индекс, а потому по одной таблице пойдёт full scan
2. индексируется ли поле sb.rate? Если нет, то на выходе получаем file sort. )) И запрос в разы медленнее.
Для проверки что глючит, надо выполнить один из тормозных запросов вручную. Если затормозит запрос - искать проблему в mysql, если нет - в php или чём либо другом.
Если данная выборка отдаст 100000 записей, поверьте, Ваш скрипт просто ляжет... и очень даже на долго (может секунд на 20 повиснуть), так как в самом запросе я не вижу limit, то предполагаю, что описанная ситуация возможна.
Да и вообще на стороне mysql клиента (в данном случае это я про php) может много чего быть... Чуть меньше возможно на js, но всё же напоследок и его стоит проверить. Тем более, очень интересно, где лежит основная логика. на сервере (php) или клиенте (js)?
P.S. С гугла на Ваш сайт никто не переплывёт. Уж поверьте, до их "находимости", быстродействия и стабильности добраться не так уж и просто. Вот например вижу, что Вы переменные прямо в запрос закидываете... это так? Если да, и при этом не используется экранирование данных, то Вашу базу поломать и получить всё что хочется (или записать всё что угодно) можно на счёт раз.
