Посмотрите, что говорит EXPLAIN EXTENDED
.
Если написано DEPENDENT SUBQUERY
или UNCACHEABLE SUBQUERY
, то оно будет переоцениваться при каждом использовании.
Это происходит, если подзапрос использует переменные сеанса или является коррелированным подзапросом.
Если этого не произойдет, скорее всего, он будет кэширован.
Если ваш случай, то подзапрос не будет кэширован, он будет переоценен в каждом UNION
'редакторе.
Ваш подзапрос, тем не менее, кажется слишком сложным. Почему бы вам просто не использовать:
SELECT id
FROM playlist_program_map ppm, programs p
WHERE ppm.playlist_id = 181
AND p.id = ppm.program_id
AND submitter_id = 32
AND feed_id = 2478
Если у вас есть индекс на playlist_program_map (playlist_id)
, этот запрос должен работать как шарм.
Не могли бы вы сказать мне еще две вещи:
- Сколько строк в
playlist_program_map
и сколько значений DISTINCT playlist_id
?
- Сколько строк в
programs
и сколько пар DISTINCT submitter_id, feed_id
?
Из вашего комментария я могу сделать вывод, что есть 10 programs
на playlist
в среднем и 200 programs
на (submitter, feed)
пары. Это означает, что ваш индекс на playlist_program_map
более избирателен, чем индекс на (submitter, feed)
, и playlist_program_map
должен быть ведущим в объединении.
Полнотекстовый индекс в вашем случае также не выглядит слишком избирательным, учитывая, что вам нужно присоединиться к 10 программам из 2 000 000 .
Вы можете попробовать следующее:
SELECT object_id, programs.created AS created
FROM playlist_program_map ppm, programs p, comments_programs cp
WHERE ppm.playlist_id = 181
AND p.id = ppm.program_id
AND p.submitter_id = 32
AND p.feed_id = 2478
AND cp.object_id = p.id
AND cp.text REGEXP 'excellent'
и повторите это для всех трех таблиц.