Меню
Что нового?

Постраничный вывод и оптимизация

mak_sim2001

Новичок
Постраничный вывод и оптимизация

У меня есть поиск по ключевому слову в базе данных(MySQL 4,...), который выбирает из таблицы 'business' компании по условию where, для каждой компании из другой таблицы 'business_businesscategory', выбирается категории этой компании(до 5 категорий у каждой компании), так же для каждой компании из таблице 'business_location' достаются все адреса компании(до 40 адресов (вообще не ограничено)), все это делается одним запросом с помощью join-ов. В результате я получаю на каждую компанию до 5*40=200 записей. Сортирую результат и для каждой компании получаю одну "строку", отправляю все в TEMPORARY TABLE, и достаю запросом с LIMIT 0 30, кол-во записей на страницу. Соответственно когда пользователь выбирает кликает страница 2 вся процедура повторяется только LIMIT 30 30 и т.д.

Сейчас в таблице business 30тыс записей и начались тормоза, а именно я замерял первый большой запрос выполняется до 7-8 sec, если он возвращает около 8 тыс. записей сортировка идет около 0,2 sec(это пока устраивает) и на все остальное уходят 0,01... sec.

Тот же запрос в phpMyAdmin(PMA) выполняется за (8069 total, Query took 0.4660 sec) даже 11тыс строк до 0,5sec правда PMA выставляет автоматом LIMIT 30 записей на страницу.

Хотел узнать можно ли как-то по другому организовать этот поиск с постраничным выводом.
 
Фанат

Фанат

oncle terrible
Команда форума
что-то странное ты пишешь

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

mak_sim2001

Новичок
Да очень сильно отличается причем как я понимаю отличия именно из за LIMIT которы PMA ставит.Хотя только что проверил поставил в PMA limit 0, 8000 время 2,5... sес но все равно разница существенная

Правда я юзаю ADODDB. Время замеряю без подключения

-~{}~ 10.06.07 20:29:

А вообще если не смотреть на SQL, сам алгоритм организации поиска нормальный или это можно как-то реализовать по другому?
 
Фанат

Фанат

oncle terrible
Команда форума
Как-то не очень понятно описание оптимизации.
ты пишешь, что выбираешь всю инфу одним запросом, но тогда зачем тебе временная таблица?
 

mak_sim2001

Новичок
Временную таблицу делал для постраничного вывода, выборки из неё с лимитом и сортировки.
Данные которые выбираются первым запросом для каждой компании содержат по несколько результатов, я имею в виду что если у компании 5 категории и три адреса то в результате запроса я получаю 15 записей а вывести мне надо только одну, но со всеми категориями и адресами, т.е. какой LIMIT будет в большом запросе я заранее незнаю.

-~{}~ 10.06.07 20:52:

Наверно можно и без временной таблицы, брать строки из масива который получается после сортировки, только все равно меня смущает что я при переходе на другую страницу я опять делаю большой запрос
 
Фанат

Фанат

oncle terrible
Команда форума
я бы на каждой странице делал три запроса
1. запрос к таблице фирм
2. запрос к таблице категорий с айдишниками полученных фирм
3. запрос к таблице локейшенов с айдишниками полученных фирм

-~{}~ 10.06.07 21:04:

а что 8 тыщ строк в таблицу загоняешь - это тебя не смущает?

-~{}~ 10.06.07 21:05:

чё-то я опять не понял
тебе обязательно вмсе локейшены фирмы показывать в таблице фирм?
 

mak_sim2001

Новичок
1. Хотел уточнить по поводу трёх запросов,
допустим:
1.1 возвращает 1000 униакльных записей(наверно даже не 1000 а 30) $results.
1.2 получается приблизительно такой:
'select ... from business_businesscetegories where
Business_id = '.$results[0]['Business_id'] . '
or
Business_id = '.$results[1]['Business_id'] . '
or
.....
or
Business_id = '.$results[30]['Business_id'] . '
';
1.3 тако-го же плана как и 2
Правильно ли я понял?

2. И это то-же смущает получается чем больше посетителей тем больше разростается база(я правильно понимаю?) Т.е. при хорошей нагрузке ниче нибудет работать.

В поиске я показываю 1 Location и кол-во сколько их всего.

Спасибо за решение, действительно должно помочь, с location я разберусь уже. И сортировка ненадо... Круто =)))

И ещё один вопрос остался если в цикле идут условия в where (как в 1.2) можно ли их сделать несколько тыс. (это вопрос к другой проблеме) или опять начнутся тормоза.
 
Фанат

Фанат

oncle terrible
Команда форума
нет, разумеется, ни в коем случае не стоит делать 1000 условий where
В поиске я показываю 1 Location и кол-во сколько их всего.
Нажмите для раскрытия...
блин! так и надо говорить! количество -то можно получить в том же запросе, через join! и один локейшен тоже!
И это то-же смущает получается чем больше посетителей тем больше разростается база(я правильно понимаю?) Т.е. при хорошей нагрузке ниче нибудет работать.
Нажмите для раскрытия...
с какой радости "ниче нибудет работать"? по какой причине?
какая связь между разрастанием базы и тормозами?
 
С.

С.

Продвинутый новичок
Для того, чтобы бы не получать всевозможные варианты строк на одну компанию, а сразу только одну строку, надо применить GROUP_CONCAT() с GROUP BY. Ну и сразу же LIMIT. Окончательный результат в одном запросе.

Примечание: GROUP_CONCAT() с двумя подсоединенными таблицами будет работать не совсем однозначно, но решаемо.
 

mak_sim2001

Новичок
фанат
Спасибо за помощь разобрался делаю 3 запроса первым выбираю кол-во результатов, вторым выбираю компании, кол-во локейшен и одну локейшен с limit, третьим беру категории работает стабильно до 0,02sec, без всяких скачков по времени.

С.
GROUP_CONCAT() с GROUP BY, тоже работает но время в PMA запроса с одной присоеденённой таблицей 1 - 1,5...sec.
Это запрос которым мерял 3тыс результатов.
[sql]
SELECT b.Business_id, b.Business_name, GROUP_CONCAT( bc.BusinessCategory_description )
FROM business AS b
INNER JOIN business_businesscategory AS bbc ON bbc.Business_id = b.Business_id
INNER JOIN businesscategory AS bc ON bc.BusinessCategory_id = bbc.BusinessCategory_id
WHERE b.Business_name like "%d%"
GROUP BY b.Business_id
[/sql]
С limit 0, 30 0.5... sec(а это значительно больше чем время которое у меня уходит при варианте предложенным фанатом там вся страница формируется за 0,05 - 0,03sec

Конечно может я что-то упустил и не корректно замерял, но мне покозалась что это в данном случае медленее, напишите если я неправ насчет этой функции.

P.S. А чего слово ***** звездочками забивается =)))
 
С.

С.

Продвинутый новичок
Я полагал, что поиск по колонкам зависимых таблиц тоже идет. А если только по b.Business_name, то смысла их присоединять в запросе поиска конечно нет.
 

mak_sim2001

Новичок
С.
О поиске по зависимым колонкам, я проверял если я делаю поиск по зависимым колонкам например по
[sql]
SELECT
...
, GROUP_CONCAT(bc.BusinessCategory_description) AS buscat_des
...
WHERE
...
buscat_des LIKE "%seminar%"
[/sql]
то он выводит не все категории соответсвующее компаниии, а только те в которых встречаются ключевые слова либо все если в них ключевые слова не встречаются, а встречаются только например в имени выводит все категории. Это как то можно подправить?
(как вариант два раза таблицу подсоеденять один раз для поиска другой для результата только боюсь что это поиск не ускорит)
И еще одна проблема как по такому полю поиск по релевантности вести, я только один вариант вижу опять возвращатся к временной таблице?
У меня вообще поиск идет по трём полям с разными коэфециентами релевантности, естественно поиск по категориям было бы очень хорошо. результаты были бы более точные.
 
С.

С.

Продвинутый новичок
Изначальный вопрос состоял в том, как найти быстрее. Здесь уже и зависимые колонки, и даже релевантность появилась, и вопрос, как вообще найти. Я не понимаю. Может все-таки от печки начать. Что нужно?
 
litvinenko

litvinenko

Новичок
У тебя с индексами в БД все нормально? Везде, где нужно, поставил?
 
Войдите или зарегистрируйтесь для ответа.
Сверху