इससे पहले कि हम समयपूर्व अनुकूलन में जाएं मोड, निम्न क्वेरी टेम्पलेट को देखना उपयोगी हो सकता है। यदि और कुछ नहीं तो इसका उपयोग आधार रेखा के रूप में किया जा सकता है जिसके विरुद्ध संभावित अनुकूलन की प्रभावशीलता को मापा जा सकता है।
SELECT T.Tagid, TagInfo.TagName, COUNT(*)
FROM Items I
JOIN Tags TagInfo ON TagInfo.TagId = T.TagId
JOIN ItemTagMap T ON I.ItemId = T.ItemId
--JOIN ItemTagMap T1 ON I.ItemId = T1.ItemId
WHERE I.ItemId IN
(
SELECT ItemId
FROM Items
WHERE -- Some typical initial search criteria
Title LIKE 'Bug Report%' -- Or some fulltext filter instead...
AND ItemDate > '02/22/2008'
AND Status = 'C'
)
--AND T1.TagId = 'MySql'
GROUP BY T.TagId, TagInfo.TagName
ORDER BY COUNT(*) DESC
सबक्वायरी "ड्राइविंग क्वेरी" है, यानी अंतिम-उपयोगकर्ता के प्रारंभिक मानदंडों के अनुरूप। (विवरण के लिए नीचे देखें कि यह क्वेरी, जिसकी कई बार आवश्यकता समग्र अनुकूलित प्रवाह में फिट हो सकती है) T1 पर जॉइन (और संभवतः T2, T3, जब कई टैग चुने जाते हैं) पर टिप्पणी की जाती है, और, WHERE क्लॉज के साथ, संबद्ध मानदंड। इनकी आवश्यकता तब होती है जब उपयोगकर्ता किसी विशेष टैग का चयन करता है, चाहे वह प्रारंभिक खोज के भाग के रूप में हो या परिशोधन द्वारा। (इन जॉइन और जहां उप-क्वेरी के भीतर क्लॉज रखना अधिक कुशल हो सकता है; नीचे इन पर और अधिक)
चर्चा... दो अलग-अलग उद्देश्यों के लिए "ड्राइविंग क्वेरी", या उसके रूपांतर की आवश्यकता है:
-
1 पूर्ण प्रदान करने के लिए ItemId की सूची जो सभी संबद्ध टैगों की गणना के लिए आवश्यक है।
-
2 आइटम तालिका में आइटम विवरण जानकारी देखने के उद्देश्य से पहला N ItemId मान (N प्रदर्शन पृष्ठ आकार होने के नाते) प्रदान करने के लिए।
ध्यान दें कि पूरी सूची को क्रमबद्ध करने की आवश्यकता नहीं है (या इसे एक अलग क्रम में क्रमबद्ध करने से लाभ हो सकता है), जिससे दूसरी सूची को उपयोगकर्ता की पसंद के आधार पर क्रमबद्ध करने की आवश्यकता होती है (जैसे दिनांक, अवरोही या शीर्षक द्वारा, वर्णानुक्रम में आरोही) ) यह भी ध्यान दें कि यदि किसी प्रकार के क्रम की आवश्यकता है, तो क्वेरी की लागत पूरी सूची से निपटेगी (एसक्यूएल द्वारा अजीब अनुकूलन की शर्मीली, और/या कुछ असामान्यकरण, एसक्यूएल को उस सूची के अंतिम रिकॉर्ड को "देखने" की आवश्यकता है , यदि वे शीर्ष से संबंधित हैं, तो क्रमबद्ध करें)।
यह बाद वाला तथ्य, दोनों उद्देश्यों के लिए एक ही प्रश्न रखने के पक्ष में है, संबंधित सूची को अस्थायी तालिका में संग्रहीत किया जा सकता है। सामान्य प्रवाह शीर्ष एन आइटम रिकॉर्ड को उनके विवरण के साथ जल्दी से देखना होगा और इसे एक ही बार में आवेदन पर वापस कर देगा। एप्लिकेशन तब अजाक्स-फ़ैशन को परिशोधन के लिए टैग की सूची प्राप्त कर सकता है। यह सूची ऊपर की तरह एक क्वेरी के साथ तैयार की जाएगी, जहां सबक्वायरी को "अस्थायी तालिका से चुनें *" द्वारा प्रतिस्थापित किया जाता है। संभावनाएं अच्छी हैं कि SQL ऑप्टिमाइज़र इस सूची (कुछ मामलों में) को सॉर्ट करने का निर्णय लेगा, आइए इसे दूसरे अनुमान लगाने और इसे स्पष्ट रूप से सॉर्ट करने के बजाय ऐसा करने दें।
विचार करने के लिए एक अन्य बिंदु यह है कि ऊपर दिखाए गए अनुसार "ड्राइविंग क्वेरी" के अंदर ItemTagMap तालिका में शामिल हों। ऐसा करना शायद सबसे अच्छा है, दोनों प्रदर्शन के लिए, और क्योंकि यह #2 उद्देश्य (आइटम के एक पृष्ठ का प्रदर्शन) के लिए सही सूची तैयार करेगा।
ऊपर वर्णित क्वेरी/प्रवाह अपेक्षाकृत मामूली हार्डवेयर पर भी बेहतर पैमाने पर होने की संभावना है; संभावित रूप से 1/2 मिलियन+ आइटम में, निरंतर उपयोगकर्ता खोजों के साथ शायद 10 प्रति सेकंड तक। प्रमुख कारकों में से एक प्रारंभिक खोज मानदंड की चयनात्मकता होगी।
अनुकूलन उपाय
- [सामान्य खोज मामलों और डेटा आँकड़ों के आधार पर] ItemTagMap तालिका में कुछ आइटम फ़ील्ड लाकर (वास्तव में डुप्लिकेट करके) इसे असामान्य बनाना समझ में आता है। विशेष रूप से छोटे क्षेत्रों का वहां 'स्वागत' किया जा सकता है।
- जैसे-जैसे डेटा मिलियन+ आइटम्स में बढ़ता है, हम कुछ टैग्स के आम तौर पर मजबूत सहसंबंध का फायदा उठा सकते हैं (उदा:SO में, PHP अक्सर MySql के साथ आता है, btw अक्सर बिना किसी अच्छे कारण के ...), विभिन्न ट्रिक्स के साथ। उदाहरण के लिए "मल्टी-टैग" टैगआईड्स की शुरूआत इनपुट लॉजिक को थोड़ा और जटिल बना सकती है, लेकिन मैप के आकार को भी काफी कम कर सकती है।
-- 'बिल्कुल नहीं कहा! --
वास्तविक आवश्यकताओं और प्रभावी डेटा सांख्यिकीय प्रोफ़ाइल के आलोक में उपयुक्त वास्तुकला और अनुकूलन का चयन किया जाना चाहिए...
