यह निश्चित रूप से नहीं है!
पूरी तरह से अवरुद्ध शब्दों से बना कोई भी खोज शब्द चुपचाप विफल हो जाएगा। शब्दों को न्यूनतम/अधिकतम लंबाई प्रतिबंधों और/या स्टॉपवर्ड फ़ाइल के कारण अवरुद्ध किया जा सकता है।
मुझे डिफ़ॉल्ट स्टॉपवर्ड फ़ाइल बहुत अधिक आक्रामक लगी, यह कई मान्य खोजों को रोक रही थी। इसके अलावा, 4 की डिफ़ॉल्ट न्यूनतम लंबाई बहुत बार ऐसे शब्दों के लिए किक कर रही थी, जिन्हें लोग खोजना चाहते हैं। मैंने ft_min_word_len को घटाकर 3 कर दिया और स्टॉपलिस्ट को पूरी तरह से हटा दिया (ft_stopword_file='')। डॉक्टर:http://dev.mysql.com /doc/refman/5.1/hi/fulltext-fine-tuning.html
आप यह देखने के लिए खोज क्वेरी की जांच भी कर सकते हैं कि क्या इसमें केवल <4-अक्षर के शब्द हैं, और उस मामले में LIKE खोज पर वापस आ सकते हैं। एप्लिकेशन स्तर पर स्टॉपलिस्ट के आसपास जाने का कोई आसान तरीका नहीं है।
हो सकता है कि 'शब्द वर्ण' का चयन आपकी ज़रूरतों को पूरा न करे, और इसे बदलना मुश्किल है। उदाहरण के लिए "टेरी" की खोज "टेरी" से मेल नहीं खाएगी। आम तौर पर किसी भी प्रकार के स्टेमिंग के लिए कोई समर्थन नहीं होता है, इसलिए "बिस्किट" "बिस्कुट" से मेल नहीं खाएगा।
अंत में, जैसा कि cg ने उल्लेख किया है, InnoDB के लिए कोई समर्थन नहीं है। इस दिन और उम्र में, आप अपने सभी डेटा को MyISAM तालिका में नहीं रखना चाहते हैं।
यदि आपके पास अतिरिक्त भंडारण है, तो आप डेटा के मुख्य, विहित संस्करण को एक InnoDB तालिका में रख सकते हैं, और फिर एक अलग MyISAM तालिका बना सकते हैं जिसमें फ़्रीटेक्स्ट सामग्री की एक प्रति होती है, विशुद्ध रूप से सर्चबैट के रूप में उपयोग के लिए। आपको परिवर्तन पर दोनों तालिकाओं को अपडेट करना होगा, लेकिन यदि MyISAM तालिका अखंडता खो देती है तो कम से कम आप वास्तविक लाइव डेटा को उछालने और एप्लिकेशन त्रुटियों को प्राप्त करने के बजाय संबंधित पंक्तियों पर खोज करने की क्षमता खो देते हैं।
फिर, यदि आपके पास अतिरिक्त चक्र हैं, तो आप उपरोक्त कुछ सीमाओं को प्राप्त करने के लिए सर्चबैट और क्वेरी शब्दों पर अपना टेक्स्ट प्रोसेसिंग लागू कर सकते हैं। उदाहरण के लिए आप उन पात्रों से बच सकते हैं जिन्हें आप शब्द-पात्र बनना चाहते हैं, उन पात्रों को हटा सकते हैं जिन्हें आप शब्द-वर्ण नहीं बनाना चाहते हैं, और सरल मैनुअल अंग्रेजी स्टेमिंग कर सकते हैं।
