Проблемът тук беше, както описах в актуализация 2 на моя въпрос. MySQL използва индекси за бързо изпълнение на операции ORDER BY. По-конкретно, MySQL използва B-дървета за индексиране на колони (като времеви печати – p.time/r.time), които заемат малко повече място, но позволяват по-бързо сортиране.
Проблемът с моята заявка беше, че сортираше по времева колона в две таблици, използвайки времевата марка от таблицата за повторно публикуване, ако е налична, и таблицата за публикуване в противен случай. Тъй като MySQL не може да комбинира B-дърветата от двете таблици, той не може да извърши бързо сортиране на индекси на колони от две различни таблици.
Промених своята заявка и структура на таблицата по два начина, за да реша това.
1) Първо извършете филтриране въз основа на блокирани потребители, така че поръчването трябва да се извършва само за публикации, които са достъпни от текущия потребител. Това не е коренът на проблема, а е практическа оптимизация. напр.
SELECT * FROM (SELECT * FROM Post p WHERE p.author_id NOT IN (4, 5, 6...))...
2) Третирайте всяка публикация като репост от нейния автор, така че всяка публикация е гарантирана, че има присъединяваща се република и repost.time, в която да индексира и сортира. напр.
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
В края на деня проблемът се сведе до ORDER BY – този подход намали времето за заявка от около 8 секунди на 20 ms.
