यहाँ समस्या थी जैसा कि मैंने अपने प्रश्न के अद्यतन 2 में वर्णित किया था। MySQL अनुक्रमित का उपयोग ORDER BY संचालन को शीघ्रता से करने के लिए करता है। अधिक विशेष रूप से, MySQL B-trees का उपयोग करता है स्तंभों को अनुक्रमित करने के लिए (जैसे टाइमस्टैम्प - p.time/r.time), जो थोड़ी अधिक जगह का उपयोग करते हैं लेकिन तेज़ सॉर्टिंग की अनुमति देते हैं।
मेरी क्वेरी के साथ समस्या यह थी कि यह दो तालिकाओं में टाइम कॉलम द्वारा सॉर्ट कर रहा था, यदि उपलब्ध हो तो रेपोस्ट टेबल से टाइमस्टैम्प का उपयोग करके, और पोस्ट टेबल अन्यथा। चूंकि MySQL दोनों तालिकाओं के B-पेड़ों को संयोजित नहीं कर सकता, इसलिए यह दो अलग-अलग तालिकाओं के स्तंभों पर तेज़ अनुक्रमणिका छँटाई नहीं कर सकता।
मैंने इसे हल करने के लिए अपनी क्वेरी और टेबल संरचना को दो तरीकों से संशोधित किया।
1) पहले ब्लॉक किए गए उपयोगकर्ताओं के आधार पर फ़िल्टरिंग करें, इसलिए ऑर्डर केवल उन पोस्ट पर किया जाना है जो वर्तमान उपयोगकर्ता द्वारा एक्सेस किए जा सकते हैं। यह समस्या की जड़ नहीं थी, बल्कि व्यावहारिक अनुकूलन है। उदा.
SELECT * FROM (SELECT * FROM Post p WHERE p.author_id NOT IN (4, 5, 6...))...
2) प्रत्येक पोस्ट को उसके लेखक द्वारा एक रीपोस्ट के रूप में मानें, इसलिए प्रत्येक पोस्ट में एक जुड़ने योग्य रीपोस्ट और रीपोस्ट होने की गारंटी है। जिस पर इंडेक्स और सॉर्ट करना है। उदा.
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 कर दिया।
