MySQL: пересечение SELECT

edogs, select not in при большой вложенной выборке виснет напрочь, к сожалению. Это я уже давно пробовал, как первое, что в голову пришло.

Тут проблема, что и джоины не спасают, если вторая выборка достаточно большая - попробовал условно годный вариант на другой таблице, намного большей - время запроса около 5-6 минут выходит. Может надо как-то через временные таблицы с индексами такие вещи делать? Честно говоря, не приходилось применять еще ни разу временные таблицы.

sidorka,

Без реальных данных тяжело советовать что-то кроме прямого подхода.

Можете хотя бы выложить полностью структуру таблиц и статистику по данным в них? Объем, количество записей, то что phpmyadmin в стате показывает.

Так же сделайте explain запроса (последнего что мы советовали) и покажите результат.

Есть еще один простой тупой подход - сделать дубли таблиц без лишних данных. Т.е. keywords2: id, catid и pages2: keyid, catid - по ним выборки будет шустрее. Встанет вопрос их наполнения и актуализации, но зачастую это решение проблемы (по сути это кэширование).

Так же архитектурный вопрос. Каким образом у Вас может быть keyid в pages но не быть id в keywords? Это ведь нарушение целостности. А если такого быть не может, то на фига Вам вообще объединение таблиц для разницы? Выбирайте просто keyid из pages и всё.

Первая таблица keywords - 1M строк, вторая pages - пока больше 300к нет, если с условиями where брать - 80к потолок сейчас. Но будет больше. Условно годный вариант с вложенным селектом дает 10-15 секунд при размере второй таблицы 25к, после where - 3к. Первая keywords статична, pages - растет. При увеличении размера второй таблицы, этот же запрос уходит в категорию неприемлемых по времени.

edogs, у меня решение в обход в принципе есть. Думал может как-то внутри мускула красиво можно провернуть, без выхода в пхп.

sidorka,

Странно что при таких данных у Вас такие скорости, должно летать.

Но при таком раскладе это только вживую, на форуме мало что подскажешь.

Однако, если keywords у Вас статическая, то дублирование ее в таблицу состоящую только из id catid - должно ускорить выборку. В том смысле что если это статика, сделайте такую же таблицу без всякого хлама для выборок.

И по тому же принципу чисто mysql решения можем предложить попробовать следующее (попробуйте запустить в PMA, только названия полей поправьте, как дальше это решать вопрос отдельный:) )

create temporary table ek select id from keywords where catid=1;

delete from ek where id in (select keyid from pages where catid=1);

select id from ek;

Возможно из-за того, что на боевом сервере так медленно.

Попробовал предложенный вариант с временной таблицей - мало, в смысле много по времени. Я раньше пробовал такие конструкции where id in select, но они при большом результате вложенного подзапроса очень медленно работают.