Требуется из таблицы keywords выбрать записи в нужной категории, которых нет в таблице pages с этой же категорией. Но это просто более частный случай нахождения пересечения - ограничение выборки.
По структуре таблиц
keywords - id - int(11), category_id - int(11) и другие к запросу не относящиеся и в выборку не попадающие. Индексы - первичный id и индекс category_id.
pages - id - int(11), category_id - int(11), keyword_id - int(11) и другие к запросу не относящиеся и в выборку не попадающие. Индексы - первичный id, составной уникальный (category_id,keyword_id)
Проверил вариант такой на основе предложенного - очень долго, не дождался ответа, прибил процесс руками после третьей минуты.
SELECT k.id FROM keywords AS k LEFT JOIN pages_1 AS p ON k.id = p.keyword_id WHERE k.category_id = 1 AND p.keyword_id IS NULL
---------- Добавлено 20.03.2016 в 16:59 ----------
Запрос с вложенным селектом показывает стабильно 10-15 секунд.
Попробовал еще один вложить селект - результат тот же. Прироста не дало
SELECT k.id FROM (SELECT id FROM keywords WHERE category_id = 1) AS k LEFT OUTER JOIN (SELECT keyword_id FROM pages_1 WHERE category_id = 1) AS p ON k.id = p.keyword_id WHERE p.keyword_id IS NULL
---------- Добавлено 20.03.2016 в 17:03 ----------
Если ограничить первый запрос без вложенного подзапроса лимитами, то выборка 10к проходит за 40-50 сек, что не гуд и все равно мало.
---------- Добавлено 20.03.2016 в 17:23 ----------
edogs, второй вариант, предложенный вами, не прошел - 89970 rows in set (6 min 22.64 sec).
SELECT k.id FROM keywords AS k LEFT JOIN pages_1 AS p ON k.id = p.keyword_id AND k.category_id = p.category_id AND k.category_id = 1 AND p.category_id = 1 WHERE p.keyword_id IS NULL
а вот такой выдает пустой результат
SELECT k.id FROM keywords AS k LEFT JOIN pages_1 AS p ON k.id = p.keyword_id AND k.category_id = p.category_id WHERE p.keyword_id IS NULL AND k.category_id = 1 AND p.category_id = 1
этот тоже пустой
SELECT k.id FROM keywords AS k LEFT JOIN pages_1 AS p ON k.id = p.keyword_id WHERE p.keyword_id IS NULL AND k.category_id = 1 AND p.category_id = 1
---------- Добавлено 20.03.2016 в 17:26 ----------
edogs: Ваш вариант в 5 посте - заведомо трэш в меру избыточного вложенности запроса.
SELECT k.id
FROM keywords AS k
LEFT OUTER JOIN (SELECT keyword_id FROM pages_1 WHERE category_id = 1) AS p
ON k.id = p.keyword_id
WHERE p.keyword_id IS NULL AND k.category_id = 1
Выборка от 15 до 45 секунд, в зависимости от текушей нагрузки сервака.
Вариант на той же базе с теми же условиями
t1 = SELECT id FROM keywords WHERE category_id = 1
t2 = SELECT keyword_id FROM pages_1 WHERE category_id = 1
php array_diff(t1, t2)
Расчитывал на гугл, получилось, что яшке больше нравится.
Тут тоже есть нюансы с обновлениями, на мой взгляд. Вот понравится псу контент, даст трафа, а потом проверит, а там уже немного другое и трафа вроде как недостойно. Думаю, может стоит замораживать страницы с трафом? Зачем дразнить псов.
Требуется из таблицы keywords выбрать записи в нужной категории, которых нет в таблице pages с этой же категорией. Но это просто более частный случай нахождения пересечения - ограничение выборки.
По структуре таблиц
keywords - id - int(11), category_id - int(11) и другие к запросу не относящиеся и в выборку не попадающие. Индексы - первичный id и индекс category_id.
pages - id - int(11), category_id - int(11), keyword_id - int(11) и другие к запросу не относящиеся и в выборку не попадающие. Индексы - первичный id, составной уникальный (category_id,keyword_id)
Проверил вариант такой на основе предложенного - очень долго, не дождался ответа, прибил процесс руками после третьей минуты.
---------- Добавлено 20.03.2016 в 16:59 ----------
Запрос с вложенным селектом показывает стабильно 10-15 секунд.
Попробовал еще один вложить селект - результат тот же. Прироста не дало
---------- Добавлено 20.03.2016 в 17:03 ----------
Если ограничить первый запрос без вложенного подзапроса лимитами, то выборка 10к проходит за 40-50 сек, что не гуд и все равно мало.
---------- Добавлено 20.03.2016 в 17:23 ----------
edogs, второй вариант, предложенный вами, не прошел - 89970 rows in set (6 min 22.64 sec).
а вот такой выдает пустой результат
этот тоже пустой
---------- Добавлено 20.03.2016 в 17:26 ----------
Ваш вариант в 5 посте - заведомо трэш в меру избыточного вложенности запроса.
этот вариант пока единственный условно пригодный
Попробовал с джоинами.
Выборка от 15 до 45 секунд, в зависимости от текушей нагрузки сервака.
Вариант на той же базе с теми же условиями
укладывается в 1-3 секунды.
Есть какие варианты ускорить запрос с джоинами?
bolyk, немного не то.
При прочих равных условия, что более активно юзает диск, если база не помещается в память, монго или мускул? Не проводил тесты?
bolyk, вопрос не по доргену.
По собственному опыту, удастся ли радикально снизить нагрузку на диск, если перейти с MySql на mongoDB или что-то подобное?
Будут конфликтовать.
А решение какое? Отказаться от cloudflare?
есть проблемы когда сайт работает через claudflare и через DDoS-Guard
Если не сложно, проясните немного подробнее сей момент.
А ПС, пс какая?
Расчитывал на гугл, получилось, что яшке больше нравится.
Тут тоже есть нюансы с обновлениями, на мой взгляд. Вот понравится псу контент, даст трафа, а потом проверит, а там уже немного другое и трафа вроде как недостойно. Думаю, может стоит замораживать страницы с трафом? Зачем дразнить псов.
Всем спасибо, нашел то, что нужно.
Только у одного меня все в порядке что ли?
С введением антиддоса тарифы изменятся?
Den73, спасибо за тест. Вот все бы так поступали, а то всегда кота в мешке предлагают. Времени заняло полчаса-час.
---------- Добавлено 10.03.2016 в 18:07 ----------
xexe77, нагрузил на 70% того, что сейчас у игоря гружу. Я ж говорю - сковородка для админов :)