Il problema qui era come ho descritto nell'aggiornamento 2 della mia domanda. MySQL utilizza gli indici per eseguire rapidamente le operazioni ORDER BY. Più specificamente, MySQL utilizza B-trees per indicizzare colonne (come timestamp - p.time/r.time), che occupano un po' più di spazio ma consentono un ordinamento più rapido.
Il problema con la mia query era che stava ordinando in base alla colonna dell'ora in due tabelle, utilizzando il timestamp dalla tabella di repost se disponibile e la tabella dei post in caso contrario. Poiché MySQL non può combinare gli alberi B di entrambe le tabelle, non può eseguire l'ordinamento rapido degli indici su colonne di due tabelle diverse.
Ho modificato la mia query e la struttura della tabella in due modi per risolvere questo problema.
1) Esegui prima il filtraggio in base agli utenti bloccati, quindi l'ordine deve essere eseguito solo sui post accessibili dall'utente corrente. Questa non era la radice del problema, ma è un'ottimizzazione pratica. es.
SELECT * FROM (SELECT * FROM Post p WHERE p.author_id NOT IN (4, 5, 6...))...
2) Tratta ogni post come un repost del suo autore, così ogni post è garantito per avere un repost e repost.time unibili su cui indicizzare e ordinare. es.
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
Alla fine della giornata, il problema è stato ORDER BY:questo approccio ha ridotto il tempo di query da circa 8 secondi a 20 ms.
