एसक्यूएल 'पसंद है' सादा 'LIKE' से धीमा है?

Question

मैं एक डीजेंगो एप्लिकेशन का उपयोग कर रहा हूं जो कुछ 'स्टार्टविथ' ओआरएम ऑपरेशंस को longtext कॉलम की तुलना एक यूनिकोड स्ट्रिंग के साथ करता है। इसका परिणाम LIKE BINARY तुलनात्मक ऑपरेशन u'mystring' यूनिकोड स्ट्रिंग के साथ होता है। एक तरह की तरह एक सादा की तुलना में धीमी गति से होने की संभावना है?

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

मैं MySQL का उपयोग कर रहा हूं लेकिन मुझे सामान्य रूप से SQL डेटाबेस के उत्तर में रूचि है।

Answer 1

यदि प्रदर्शन एक समस्या बनने लगता है, तो पहले उदाहरण की एक प्रति बनाने के लिए एक अच्छा विचार हो सकता है। लांगटेक्स्ट के 255 वर्ण, उस पर एक इंडेक्स जोड़ें और उसके साथ startswith का उपयोग करें।

बीटीडब्ल्यू, this page says: "यदि आपको केस-सेंसिटिव मिलान करने की आवश्यकता है, तो अपने कॉलम को बिनरी के रूप में घोषित करें; गैर-बाइनरी कॉलम डालने के लिए अपने प्रश्नों में LIKE BINARY का उपयोग न करें। यदि आप करते हैं, तो MySQL नहीं होगा उस कॉलम पर किसी भी इंडेक्स का उपयोग करें। " यह एक पुरानी नोक है लेकिन मुझे लगता है कि यह अभी भी वैध है।

Answer 2

अगले व्यक्ति इस पर चलने वाले के लिए

- हमारे अपेक्षाकृत छोटे डेटाबेस में क्वेरी:

SELECT * FROM table_name WHERE field LIKE BINARY 'some-field-search-value'; 

... Result row 

Returns 1 row in set (0.32 sec) 

लंबी कहानी संक्षेप में, कम से कम हमारे डाटाबेस के लिए (MySQL 5.5:

SELECT * FROM table_name WHERE field LIKE 'some-field-search-value'; 

... Result row 

Returns 1 row in set (0.00 sec) 

की तुलना/InnoDB) दो लुकअप के बीच प्रदर्शन में एक बहुत ही महत्वपूर्ण अंतर है।

जाहिर है, हालांकि यह MySQL 5.5 में एक बग है: http://bugs.mysql.com/bug.php?id=63563 और MySQL 5.1 में एक ही डाटाबेस के खिलाफ मेरे परीक्षण में तरह बायनरी क्वेरी अभी भी सूचकांक (। जबकि 5.5 में यह एक पूर्ण तालिका स्कैन करता है)