2008-11-03 24 views
6

मैं उन सभी पंक्तियों को खोजने के लिए एक टेबल खोजना चाहता हूं जहां एक विशेष फ़ील्ड दो मानों में से एक है। मुझे पता है कि मूल्य क्या होंगे, लेकिन मुझे आश्चर्य है कि उनके लिए खोज करने का सबसे प्रभावी तरीका कौन सा है:इन या टेक्स्ट खोज का उपयोग

उदाहरण के लिए, दो मान "xpoints" और "ypoints" हैं। मुझे विश्वास है कि वहाँ कि क्षेत्र है जो अंत में "अंक" है में कोई अन्य मान होंगे गया है, इसलिए दो प्रश्नों मैं विचार कर रहा हूँ कर रहे हैं:

WHERE `myField` IN ('xpoints', 'ypoints') 
--- or... 
WHERE `myField` LIKE '_points' 

जो इस मामले में सबसे अच्छा परिणाम देना होगा?

उत्तर

14

हमेशा SQL क्वेरी के साथ, इसे खोजने के लिए प्रोफाइलर के माध्यम से चलाएं। हालांकि, मेरे आंत वृत्ति को कहना होगा कि आईएन खोज तेज होगी। विशेष रूप से आपके द्वारा दिए गए उदाहरण में, यदि फ़ील्ड को अनुक्रमित किया गया था, तो उसे केवल 2 लुकअप करना होगा। यदि आपने एक जैसी खोज की है, तो उसे स्कैन करना पड़ सकता है, क्योंकि आप एक निश्चित मूल्य के साथ समाप्त होने वाले रिकॉर्ड ढूंढ रहे हैं। यह और भी सटीक होगा क्योंकि LIKE '_points' भी 'gpoints', या किसी अन्य समान स्ट्रिंग को वापस कर सकता है।

+0

बेशक, यह तालिका के वास्तविक आकार पर निर्भर करेगा ... यदि यह छोटा है तो ऑप्टिमाइज़र बस टेबल स्कैन का चयन करेगा। –

1

जब तक कॉलम में मौजूद सभी डेटा आइटम 'x' या 'y' से शुरू नहीं होते हैं, तो मेरा मानना ​​है कि आईएन हमेशा आपको एक बेहतर क्वेरी देगा। अगर इसे अनुक्रमित किया गया है, जैसा कि @ किबीबी बताते हैं, तो आपको दोनों को प्राप्त करने के लिए केवल 2 लुकअप करना होगा। वैकल्पिक रूप से, अगर इसे अनुक्रमित नहीं किया गया है, तो आईएन का उपयोग करके एक टेबल स्कैन को केवल अधिकांश समय को पहले अक्षर की जांच करनी होगी जबकि LIKE के साथ इसे हर बार दो अक्षर जांचना होगा (मान लें कि सभी आइटम कम से कम 2 अक्षर हैं) - चूंकि पहले चरित्र को कुछ भी होने की अनुमति है।

0

इसे आज़माएं और देखें। परीक्षण डेटा की एक बड़ी मात्रा बनाएं, इसके अलावा, इसे मेरे क्षेत्र में इंडेक्स के साथ और बिना प्रयास करें। जब आप इसमें हों, तो देखें कि LIKE 'अंक' और LIKE 'xpoint' के बीच कोई उल्लेखनीय अंतर है या नहीं।

यह प्रत्येक क्वेरी के साथ अनुकूलक क्या करता है इस पर निर्भर करता है।

डेटा की थोड़ी मात्रा के लिए, अंतर नगण्य होगा। जो कुछ भी अधिक समझ में आता है करो। बड़ी मात्रा में डेटा के लिए डिस्क I/O की मात्रा CPU समय की मात्रा से अधिक मायने रखती है।

मैं शर्त लगा रहा हूं कि यदि आपके क्षेत्र में कोई इंडेक्स है तो आपको LIKE से बेहतर परिणाम मिलेंगे। मैं यह भी शर्त लगा रहा हूं कि 'xpoint_' '_points' से तेज़ चलता है। लेकिन खुद को कोशिश करने की तरह कुछ भी नहीं है।

0

MySQL स्ट्रिंग तुलना जैसे LIKE '% foo' या '_foo' का उपयोग करते समय एक अनुक्रमणिका का उपयोग नहीं कर सकता है, लेकिन 'foo%' और 'foo_' जैसी तुलनाओं के लिए एक अनुक्रमणिका का उपयोग कर सकता है।

तो आपके मामले में, IN बहुत अधिक तेजी से माना जाएगा कि फ़ील्ड अनुक्रमित है।

यदि आप संभावित मूल्यों के सीमित सेट के साथ काम कर रहे हैं, तो फ़ील्ड को ईएनएन के रूप में निर्दिष्ट करने के लायक है - MySQL फिर इसे आंतरिक रूप से एक पूर्णांक के रूप में संग्रहीत करेगा और इस तरह के लुकअप को बहुत तेज बना देगा, और डिस्क स्थान को सहेज देगा।

0

LIKE-version की तुलना में इन-संस्करण करना तेज़ होगा। विशेष रूप से जब आपका वाइल्डकार्ड तुलना के अंत में नहीं होता है, लेकिन आदर्श परिस्थितियों में भी तब तक आदर्श होगा जब तक आपकी क्वेरी आपके अधिकतम-क्वेरी सम्मिलन के आकार के नजदीक न हो।

संबंधित मुद्दे