- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Нужно вывести похожие записи по тегам, есть три таблицы
Первыя таблицы с постами
Вторая таблица с тегами
Третья таблица связка
Где tag_id - TABLE_2.id
А post_id - TABLE.id
Есть так же запрос вида
Данный запрос долгонько выполняется, в таблицах очень много записей и хотелось бы сделать что то менее нагруженное, уже 2 два дня ковыряю и ни к чему лучшему пока не пришел.
А зачем столько городить?
Зачем делать SELECT *, если, например, содержимое записи (TEXT) не нужен.
Зачем делать хитрые JOIN-ы, если запросы по PK выполняются в разы быстрее..
Показательно не количество запросов, а время их выполнения.
А самый быстрый запрос - тот, который не сделан.
На странице ведь тэги выводятся.. значит, полагаю, можно без запроса, уже в коде получить их ID-шники и сделать из них через запятую что-то вроде такого:
Далее 2 "простых" запроса по ключу:
Ещё есть смысл индексы перепроверить...
А зачем столько городить?
Зачем делать SELECT *, если, например, содержимое записи (TEXT) не нужен.
Зачем делать хитрые JOIN-ы, если запросы по PK выполняются в разы быстрее..
Показательно не количество запросов, а время их выполнения.
Это все понятно, это не мой запрос, я даже четко его разобрать не в силах, одна каша.
Знаю только то, что он был написан в 2007 году, наверное тогда это было нормой.
А самый быстрый запрос - тот, который не сделан.
На странице ведь тэги выводятся.. значит, полагаю, можно без запроса, уже в коде получить их ID-шники и сделать из них через запятую что-то вроде такого:
Со страницы могу взять только ID поста, в смысле TABLE_3.id_post
А если получать ID всех тегов в посте, придется делать еще одну склейку таблиц с TABLE_2 (думаю смысла в этом нет) и быстрее наверное будет сделать отдельную выборку из TABLE_3, получив при этом все TABLE_2.id (все id тегов)
Тем самым получить уже все id_tag
Далее 2 "простых" запроса по ключу:
Ещё есть смысл индексы перепроверить...
Побег кумекать, тестить :) спасибо!
Ну если еще варианты будут, тоже будет интересно поглядеть =)
какя-то каша в запросе.
В подзапросе линкуем TABLE3 саму на себя, TABLE1 там не нужна
как-то так подзапрос, не проверял:
к подзапросу линкуем TABLE1 как обычно.
проверьте еще чтобы на TABLE3 было 3 индекса:
уникальный индекс: post_id, tag_id или (tag_id, post_id)
обычный индекс: tag_id
обычный индекс: post_id
по индексам
post_id и tag_id c INDEX идут
и плюсом
Эти два поля уникальные в данной таблицу.
уникальный индекс: post_id, tag_id или (tag_id, post_id)
обычный индекс: tag_id
обычный индекс: post_id
post_id, tag_id - PK (полагаю)
tag_id - INDEX
а зачем отдельный индекс по post_id?
какя-то каша в запросе.
TABLE1 там не нужна
Она нужно, так как нужно именно их нее выдернуть данные, в данном случае (title и id)
Нет. unique выставлено
В TABLE_2 и TABLE_3
данных хранятся в таком виде
Где 100 это TABLE.id = 100
Она нужно, так как нужно именно их нее выдернуть данные, в данном случае (title и id)
В подзапросе не нужна. В смысле, на весь запрос достаточно одного упоминания этой таблицы.
ivan-lev, собрал запрос, вроде бы все получилось, единственно указал еще post_id != 100
А то выводил такой же пост где я и нахожусь.
Работает быстро что очень радует, время выполнения 0.003-0.008 сек
Единственно что пришлось два раза перебирать выборку, первый раз получить ID всех тегов
Получил
Далее перебор
Затем новый запрос
Получил
Далее опять перебор
И уже последний запрос выводит то что мне нужно
Работает как и говорил быстро, если учесть что запрос из первого поста работал
0.1-0.3 сек
ivan-lev, о такой выборке вы писали? Или я тут уже отсебячины нагородил? 🤪
Далее перебор
Для получения всех значений из 1 колонки удобно использовать fetchAll с FETCH_COLUMN
Суть не меняется, зато код компактнее и понятнее.
Без вас бы не справился =) Спасибо!