Caché/reutilización de una subconsulta en MySQL

Ver lo que EXPLAIN EXTENDED dice.

Si dice DEPENDENT SUBQUERY o UNCACHEABLE SUBQUERY , luego se volverá a evaluar cada vez que se use.

Esto sucede si la subconsulta usa variables de sesión o es una subconsulta correlacionada.

Si no es así, lo más probable es que se almacene en caché.

Si su caso, la subconsulta no se almacenará en caché, se reevaluará en cada UNION 'ed conjunto.

Sin embargo, su subconsulta parece ser demasiado complicada. ¿Por qué no usas simplemente:

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

Si tiene un índice en playlist_program_map (playlist_id) , esta consulta debería funcionar a las mil maravillas.

¿Podría decirme dos cosas más?:

1. ¿Cuántas filas hay en playlist_program_map? y cuántos DISTINCT playlist_id valores hay?
   • ¿Cuántas filas hay en programs? y cuántos DISTINCT submitter_id, feed_id pares hay?

De tu comentario puedo concluir que hay 10 programs por playlist en promedio, y 200 programs por (submitter, feed) par. Esto significa su índice en playlist_program_map es más selectivo que el de (submitter, feed) y playlist_program_map debe estar al frente en la unión.

El índice de texto completo en su caso tampoco parece ser muy selectivo, dado que debe unirse a 10 programas de 2,000,000 .

Es mejor que pruebes lo siguiente:

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'

y repita esto para las tres tablas.