तीन पूर्ण टेक्स्ट इंडेक्स बनाएं
- a) कीवर्ड कॉलम पर एक
- b) सामग्री कॉलम पर एक
- c) कीवर्ड और सामग्री कॉलम दोनों पर एक
फिर, आपकी क्वेरी:
SELECT id, keyword, content,
MATCH (keyword) AGAINST ('watermelon') AS rel1,
MATCH (content) AGAINST ('watermelon') AS rel2
FROM table
WHERE MATCH (keyword,content) AGAINST ('watermelon')
ORDER BY (rel1*1.5)+(rel2) DESC
मुद्दा यह है कि rel1 आपको केवल keyword . में आपकी क्वेरी की प्रासंगिकता प्रदान करता है कॉलम (क्योंकि आपने केवल उस कॉलम पर इंडेक्स बनाया है)। rel2 वही करता है, लेकिन content . के लिए कॉलम। अब आप इन दो प्रासंगिकता स्कोरों को एक साथ जोड़ सकते हैं, अपनी पसंद के किसी भी भार को लागू करते हुए।
हालाँकि, आप वास्तविक खोज के लिए इन दोनों में से किसी एक अनुक्रमणिका का उपयोग नहीं कर रहे हैं। उसके लिए आप अपनी तीसरी अनुक्रमणिका का उपयोग करें, जो दोनों स्तंभों पर है।
इंडेक्स ऑन (कीवर्ड, कंटेंट) आपके रिकॉल को नियंत्रित करता है। उर्फ, क्या लौटाया।
दो अलग-अलग इंडेक्स (केवल कीवर्ड पर एक, केवल सामग्री पर एक) आपकी प्रासंगिकता को नियंत्रित करते हैं। और आप यहां अपना स्वयं का भार मानदंड लागू कर सकते हैं।
ध्यान दें कि आप किसी भी संख्या में विभिन्न इंडेक्स का उपयोग कर सकते हैं (या, अन्य कारकों के आधार पर आपके द्वारा क्वेरी समय पर उपयोग किए जाने वाले इंडेक्स और वेटिंग में भिन्नता हो सकती है ... केवल कीवर्ड पर खोज करें यदि क्वेरी में स्टॉप वर्ड है ... के लिए वेटिंग पूर्वाग्रह कम करें कीवर्ड यदि क्वेरी में 3 से अधिक शब्द हैं ... आदि)।
प्रत्येक अनुक्रमणिका डिस्क स्थान का उपयोग करती है, इसलिए अधिक अनुक्रमणिका, अधिक डिस्क। और बदले में, mysql के लिए उच्च मेमोरी फ़ुटप्रिंट। साथ ही, इंसर्ट में अधिक समय लगेगा, क्योंकि आपके पास अपडेट करने के लिए और इंडेक्स हैं।
आपको अपनी स्थिति के लिए बेंचमार्क प्रदर्शन (बेंचमार्किंग के लिए MySQL क्वेरी कैश को बंद करने के लिए सावधान रहना चाहिए अन्यथा आपके परिणाम खराब हो जाएंगे)। यह Google ग्रेड कुशल नहीं है, लेकिन यह बहुत आसान और "आउट ऑफ़ द बॉक्स" है और यह निश्चित रूप से प्रश्नों में "पसंद" के आपके उपयोग से बहुत बेहतर है।
मुझे लगता है कि यह वास्तव में अच्छा काम करता है।
