Cache/reutilização de uma subconsulta no MySQL

Veja o que EXPLAIN EXTENDED diz.

Se estiver escrito DEPENDENT SUBQUERY ou UNCACHEABLE SUBQUERY , ele será reavaliado cada vez que for usado.

Isso acontece se a subconsulta usar variáveis de sessão ou for uma subconsulta correlacionada.

Se isso não acontecer, provavelmente será armazenado em cache.

Se no seu caso a subconsulta não for armazenada em cache, ela será reavaliada em cada UNION foi definido.

Sua subconsulta, no entanto, parece ser muito complicada. Por que você simplesmente não usa:

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

Se você tiver um índice em playlist_program_map (playlist_id) , essa consulta deve funcionar como um encanto.

Você poderia me dizer mais duas coisas:

Quantas linhas existem em playlist_program_map e quantos DISTINCT playlist_id valores existem?
- Quantas linhas existem em programs e quantos DISTINCT submitter_id, feed_id pares existem?

Pelo seu comentário, posso concluir que existem 10 programs por playlist em média, e 200 programs por (submitter, feed) par. Isso significa que seu índice em playlist_program_map é mais seletivo que o de (submitter, feed) e playlist_program_map deve estar liderando na junção.

O índice de texto completo no seu caso também não parece ser muito seletivo, já que você precisa juntar 10 programas de 2.000.000 .

Você pode tentar melhor o seguinte:

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'

e repita isso para todas as três tabelas.