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

Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
В общем ситуация такова: есть три РДФ-таблицы (если кто не знает - структура у них "вирт.таблица", "поле","значение"), т.е. виртуальная оболочка обычных таблиц с нефиксированным числом полей. Естественно все запросы по выборке из таких таблиц требуют наличия JOIN, как правило из 3-5 таблиц.
Плюс когда к запросу добавляется запрос по различным запросам, для его выполнения используется как минимум подзапрос, а чаще Intersect. Версия MySQL предположительно 4, т.е. VIEW не поддерживаются.
Соответственно вопрос: что быстрее и менее напряжно для сервера в общем, писать сложнохитроумные 6этажные запросы и на уровне муськи отсеивать ненужные значения, или сделать общую выборку с минимальной фильтрацией один раз, а потом из неё перебором на PHP выкидывать ненужные?
Желательно, если кто подскажет, в двух ситуациях:
1) PHP5+MySQL4
1) PHP5+MySQL+XCache (APC, eAccelerate - подставить нужное)
склоняюсь к отдаче всей работы к мускуле, ибо он сам умеет кешировать результаты запросов + надо писать запросы которые по максимум используют индексы и ключи таблиц, ну и в завершение, можно делать хитроумные запросы, которые будут не целые таблицы тягать, а только нужные их кусочки ;)
select * from table inner join (select * from tbale 2 where user_id in (10,20,23,123,23)) as t ON t.id=table.id
такое будет выполнятся быстрее, чем просто отджойненные таблицы.
можно плюс если помог)
ну и в минус для пхп то, что можно и на пхп отсеивать, но если будет результатов пара тысяч, скорость упадет сильнее, чем если вы будете использовать хитроумные запросы :)
склоняюсь к отдаче всей работы к мускуле, ибо он сам умеет кешировать результаты запросов + надо писать запросы которые по максимум используют индексы и ключи таблиц, ну и в завершение, можно делать хитроумные запросы, которые будут не целые таблицы тягать, а только нужные их кусочки ;)
ну и в минус для пхп то, что можно и на пхп отсеивать, но если будет результатов пара тысяч, скорость упадет сильнее, чем если вы будете использовать хитроумные запросы :)
В общем то вопрос и был в том, сильно ли будет розниться по времени выполнения хитроумный запрос с отсевом и без (при условии что для фильтра по каждому полю нужен подзапрос). И где она эта граница между быстродействием муськи и пхп?
граница в количестве обрабатываемых данных, если тебе надо будет отсеять пару тысяч, то у тебя пхп заметно сдаст скорость.
если даш мускулю пару тысяч отсеять, то это сделает мгновенно, от только вопрос как ты составишь запрос, так и будет по скорости :)
bearman добавил 04.06.2008 в 14:46
ну и как факт, я предпочитаю использовать "муську" по максимуму, ибо пхп в лбом случае может сильно снизить скорость. а хитрые запросы проверяют через select sql_no_cache ....
чтобы посмотреть сколько в реале будет запрос выполняться.