El problema aquí fue como lo describí en la actualización 2 de mi pregunta. MySQL usa índices para realizar operaciones ORDER BY rápidamente. Más específicamente, MySQL usa B-trees para indexar columnas (como marcas de tiempo - p.time/r.time), que ocupan un poco más de espacio pero permiten una clasificación más rápida.
El problema con mi consulta fue que estaba ordenando por la columna de tiempo en dos tablas, usando la marca de tiempo de la tabla de reenvío si estaba disponible, y la tabla de publicación de lo contrario. Dado que MySQL no puede combinar los árboles B de ambas tablas, no puede realizar una ordenación rápida de índices en columnas de dos tablas diferentes.
Modifiqué mi estructura de consulta y tabla de dos maneras para resolver esto.
1) Realice el filtrado en función de los usuarios bloqueados primero, por lo que el pedido solo debe realizarse en las publicaciones a las que puede acceder el usuario actual. Esta no era la raíz del problema, pero es una optimización práctica. por ejemplo
SELECT * FROM (SELECT * FROM Post p WHERE p.author_id NOT IN (4, 5, 6...))...
2) Tratar cada publicación como una reenvío de su autor, por lo que se garantiza que cada publicación tenga un reenvío y un tiempo de reenvío para indexar y ordenar. por ejemplo
SELECT * FROM (...) LEFT JOIN p.reposts repost ON (p.id = repost.post_id AND
repost.time = (
SELECT MIN(r.time) FROM Repost r WHERE p.id = r.post_id
AND r.user_id IN (1, 2, 3...) AND r.user_id NOT IN (4, 5, 6...))
))
WHERE (repost.id IS NOT NULL) ORDER BY repost.time DESC LIMIT 0, 10
Al final del día, el problema se redujo a ORDENAR POR:este enfoque redujo el tiempo de consulta de aproximadamente 8 segundos a 20 ms.
