- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
А у вас и есть JOIN (INNER), просто формат записи у него такой.
Наберите EXPLAIN SELECT ... и дальше весь код и можно в личку, помогу чем смогу.
Здравствуйте ещё раз!
Что лучше 10 запросов в цикле и меньшее время генерации страницы
Или 1 запрос и большее время генерации
Скрипт1
Скрипт2
В итоге второй скрипт занимает больше времени но 1 запрос. Что лучше использовать в таком случае?
adrin02, кому лучше ? грузинам?
оба подхода гавно, в общем то как и сказал нетвайнд.
оба подхода гавно, в общем то как и сказал нетвайнд.
Ну тогда скажите какой подход будет лучше ☝
нет. ну откуда нам знать чему ему следует отдать предпочтение при выборе из противоположных целей ?
в одной конфигурации, например с выделенным mysql-сервером может оказаться, что задержки сети влияют значительно на общее время обработки запроса. А в другой с совмещенным php и mysql простые мелкие запросы обрабатываются лучше одного сложного.
Я так думаю, тут просто нечисто время замерено. Вот там выше он пишет, что УЖЕ поднялась посещаемость. Значит ее колебания могут повлиять на результаты замеров. На VPS так что угодно может повлиять.
Не может быть, чтобы один запрос по смыслу заменяющий 10 других был медленнее.
В общем и целом, нужно сделать полное нагрузочное тестирование приложения, максимально похожее на реальную одновременную работу многих пользователей с сайтом, чтобы уверенно рассуждать о пользе тех или иных действий.
в каждом случае все индивидуально.
если запрос не сильно сложный в котором не очень много данных, то лучше все сделать в одном запросе.
имхо
Погонял различные скрипты. Если count(*) то лучше в цикле., Так как в одном запросе почему то долго думает. Пробовал различные результаты и всегда время затрачивается большое.
А вообще count лучше использовать как можно реже. =)
есть альтернатива?
ну собственно его и используют редко :)
а. результаты можно кешировать, не так часто они нужны.
б. то что вы считаете можно просто внести в соотвествующее поле в БД.
например, кол-во сообщений пользователя, раньше вы делали через count но можно в базе данных пользователя сделать доп поле user_comment_qty в котором инкриментировать данные при добавлении собщения.
Да, возможно, надо будет больше кода и размер бд, но это уменьшит нагрузку на сервер.
adrin02, как я понимаю Вам нужно посчитать кол-во новостей в каждой из категорий. При этом новость может быть в одной, двух или сразу трех категориях?
Запрос
SELECT COUNT(*) FROM news WHERE cat=cat.id OR cat2=cat.id OR cat3=cat.id
скорее всего будет типа ALL независимо от индексов, т.е скан всех записей в таблице. При росте кол-ва записей в news все будет хуже и хуже работать.
Могу посоветовать только 2 варианта оптимизации:
1. вынести категории новостей в отдельную таблицу, что-то типа
create table news_category (
category_id int(11) unsigned not null,
news_id int(11) unsigned not null,
key (category_id, news_id)
) Engine=..
При добавлении новости вписывать 1-3 строчки в эту таблицу. При удалении удалять. При изменении категории обновлять.
Тогда посчитать кол-во новостей в каждой категории можно примерно так:
select c.id, count(*) from categories c inner join news_category nc on nc.category_id = c.id group by c.id;
Запрос будет использовать индексы по categories.id и индекс из news_category, это всяко быстрее чем полный скан таблицы.
2. В categories добавить новое поле типа news_counter и изменять его при добавлении/удалении новости, как в топике уже советовали.