बराबर (=) बनाम LIKE


281

SQL का उपयोग करते समय, क्या इसके बजाय =किसी WHEREखंड में उपयोग करने के कोई लाभ हैं LIKE?

किसी भी विशेष ऑपरेटरों के बिना, LIKEऔर =समान हैं, है ना?


4
एक DB प्रकार निर्दिष्ट करना चाहते हो सकता है ... mssql, mysql, oracle?
एलन चावल

1
आपके प्रश्न में कम से कम 5वोट हैं जैसे ऑपरेटर टैग के लिए। क्या मैं आपसे अनुरोध कर सकता हूं कि आप एक समानार्थक शब्द के रूप में sql- सुझाव दें ?
कर्मी

@FreshPrinceOfSO, मैं वह करूँगा जब मुझे पर्याप्त प्रतिष्ठा मिलेगी। धन्यवाद।
ट्रैविस

जवाबों:


271

विभिन्न ऑपरेटरों

LIKEऔर =अलग-अलग ऑपरेटर हैं। यहां अधिकांश उत्तर वाइल्डकार्ड समर्थन पर ध्यान केंद्रित करते हैं, जो इन ऑपरेटरों के बीच एकमात्र अंतर नहीं है!

=एक तुलना ऑपरेटर है जो संख्याओं और तारों पर काम करता है। स्ट्रिंग्स की तुलना करते समय, तुलना ऑपरेटर पूरे स्ट्रिंग्स की तुलना करता है

LIKEएक स्ट्रिंग ऑपरेटर है जो चरित्र की तुलना चरित्र से करता है

मामलों को जटिल करने के लिए, दोनों ऑपरेटर एक टकराव का उपयोग करते हैं जो तुलना के परिणाम पर महत्वपूर्ण प्रभाव डाल सकते हैं।

प्रेरक उदाहरण

आइए पहले एक उदाहरण की पहचान करें जहां ये ऑपरेटर स्पष्ट रूप से अलग-अलग परिणाम देते हैं। मुझे MySQL मैनुअल से उद्धृत करने की अनुमति दें:

SQL मानक के अनुसार, LIKE प्रति-वर्ण आधार पर मिलान करता है, इस प्रकार यह परिणाम = तुलना ऑपरेटर से भिन्न परिणाम उत्पन्न कर सकता है:

mysql> SELECT 'ä' LIKE 'ae' COLLATE latin1_german2_ci;
+-----------------------------------------+
| 'ä' LIKE 'ae' COLLATE latin1_german2_ci |
+-----------------------------------------+
|                                       0 |
+-----------------------------------------+
mysql> SELECT 'ä' = 'ae' COLLATE latin1_german2_ci;
+--------------------------------------+
| 'ä' = 'ae' COLLATE latin1_german2_ci |
+--------------------------------------+
|                                    1 |
+--------------------------------------+

कृपया ध्यान दें कि MySQL मैनुअल के इस पृष्ठ को स्ट्रिंग तुलनात्मक कार्य कहा जाता है , और =इस पर चर्चा नहीं की जाती है, जिसका अर्थ है कि =कड़े तुलना फ़ंक्शन नहीं है।

कैसे =काम करता है ?

एसक्यूएल स्टैंडर्ड § 8.2 वर्णन करता है कि =तार तुलना:

दो वर्ण तारों की तुलना निम्नानुसार निर्धारित की जाती है:

a) यदि X के वर्णों की लंबाई Y के वर्णों में लंबाई के बराबर नहीं है, तो तुलना के प्रयोजनों के लिए छोटी स्ट्रिंग को प्रभावी रूप से प्रतिस्थापित किया जाता है, इसकी एक प्रति के साथ जिसकी लंबाई स्ट्रिंग की लंबाई तक बढ़ा दी गई है एक या एक से अधिक पैड कैरेक्टर के दाईं ओर कॉन्सेप्टेशन द्वारा, जहां पैड कैरेक्टर को CS के आधार पर चुना जाता है। यदि CS में कोई PAD विशेषता नहीं है, तो पैड वर्ण X और Y के वर्ण सेट में किसी भी वर्ण से भिन्न एक कार्यान्वयन-निर्भर चरित्र है जो CS के अंतर्गत किसी स्ट्रिंग से कम टकराता है। अन्यथा, पैड चरित्र एक है।

b) X और Y की तुलना का परिणाम कोलाटिंग अनुक्रम CS द्वारा दिया गया है।

ग) कोलाटिंग अनुक्रम के आधार पर, दो तारों की तुलना समान हो सकती है, भले ही वे अलग-अलग लंबाई के हों या पात्रों के विभिन्न अनुक्रम हों। जब ऑपरेशन MAX, MIN, DISTINCT, एक समूहीकरण कॉलम के संदर्भ में, और UNION, EXCEPT, और INTERSECT ऑपरेटर वर्ण स्ट्रिंग्स को संदर्भित करते हैं, तो इन समान मानों के सेट से इन परिचालनों द्वारा चयनित विशिष्ट मूल्य कार्यान्वयन-निर्भर है।

(महत्व दिया।)

इसका क्या मतलब है? इसका मतलब है कि जब तारों की तुलना की जाती है, तो =ऑपरेटर वर्तमान टकराव के चारों ओर एक पतला आवरण होता है। एक टकराव एक पुस्तकालय है जिसमें तार की तुलना करने के लिए विभिन्न नियम हैं। यहाँ MySQL से द्विआधारी टकराव का एक उदाहरण दिया गया है :

static int my_strnncoll_binary(const CHARSET_INFO *cs __attribute__((unused)),
                               const uchar *s, size_t slen,
                               const uchar *t, size_t tlen,
                               my_bool t_is_prefix)
{
  size_t len= MY_MIN(slen,tlen);
  int cmp= memcmp(s,t,len);
  return cmp ? cmp : (int)((t_is_prefix ? len : slen) - tlen);
}

यह विशेष टकराव बाइट-बाइट की तुलना में होता है (यही कारण है कि इसे "बाइनरी" कहा जाता है - यह स्ट्रिंग्स को कोई विशेष अर्थ नहीं देता है)। अन्य टकराव अधिक उन्नत तुलना प्रदान कर सकते हैं।

उदाहरण के लिए, यहां UTF-8 समतलीकरण है जो केस-असंवेदनशील तुलनाओं का समर्थन करता है। कोड यहां पेस्ट करने के लिए बहुत लंबा है, लेकिन उस लिंक पर जाएं और के शरीर को पढ़ें my_strnncollsp_utf8mb4()। यह टकराव एक बार में कई बाइट्स को संसाधित कर सकता है और यह विभिन्न ट्रांसफ़ॉर्म (जैसे केस असंवेदनशील तुलना) लागू कर सकता है। =ऑपरेटर पूरी तरह से मिलान की अनियमितता से निकाला गया है।

कैसे LIKEकाम करता है ?

एसक्यूएल स्टैंडर्ड § 8.5 वर्णन करता है कि LIKEतार तुलना:

<विधेय>

M LIKE P

सच है अगर वहाँ एम विभाजन का अस्तित्व में है जैसे कि:

i) M का एक विकल्प 0 का अनुक्रम है या अधिक सन्निहित <चरित्र प्रतिनिधित्व> M का है और M का प्रत्येक <वर्ण प्रतिनिधित्व> वास्तव में एक प्रतिस्थापन का हिस्सा है।

ii) यदि P का i-th विकल्प निर्दिष्ट करने वाला एक मनमाना वर्ण विनिर्देशक है, तो M का i-th विकल्प किसी एकल <वर्ण प्रतिनिधित्व> है।

iii) यदि P का i-th विकल्प निर्दिष्ट करने वाला एक मनमाना स्ट्रिंग विनिर्देशक है, तो M का i-th विकल्प 0 या अधिक <वर्ण प्रतिनिधित्व> s का कोई अनुक्रम है।

iv) यदि P का i-th विकल्प निर्दिष्ट करने वाला न तो एक मनमाना वर्ण विनिर्देशक है और न ही एक मनमाना स्ट्रिंग विनिर्देशक है, तो M का i-th विकल्प उस प्रतिस्थापन निर्दिष्टक के अनुसार <प्रतिस्थापन की तरह; M के लिए <space> वर्णों का अपडेशन, और उस स्पेसिफिक स्पेसियर के समान लंबाई है।

v) M के सबस्ट्रिंग की संख्या P के स्थानापन्न विनिर्देशक की संख्या के बराबर है।

(महत्व दिया।)

यह बहुत ही चिंताजनक है, तो चलिए इसे तोड़ते हैं। आइटम ii और iii क्रमशः वाइल्डकार्ड _और संदर्भित करते %हैं। यदि Pकोई वाइल्डकार्ड नहीं है, तो केवल आइटम iv लागू होता है। यह ओपी द्वारा लगाए गए ब्याज का मामला है।

इस मामले में, यह प्रत्येक "प्रतिस्थापन" (व्यक्तिगत पात्रों) की Mतुलना Pवर्तमान टकराव का उपयोग करने वाले प्रत्येक प्रतिस्थापन के खिलाफ करता है ।

निष्कर्ष

लब्बोलुआब यह है कि तार की =तुलना करते LIKEसमय, एक बार में एक चरित्र की तुलना करते समय पूरे स्ट्रिंग की तुलना करते हैं । दोनों तुलनाएं वर्तमान टकराव का उपयोग करती हैं। यह अंतर कुछ मामलों में विभिन्न परिणामों की ओर जाता है, जैसा कि इस पोस्ट में पहले उदाहरण में स्पष्ट किया गया है।

आपको किसका उपयोग करना चाहिए? कोई भी आपको यह नहीं बता सकता है कि - आपको अपने उपयोग के मामले के लिए सही उपयोग करने की आवश्यकता है। तुलना ऑपरेटरों को स्विच करके समय से पहले अनुकूलन न करें।


4
"एक्वाइस बाइट द्वारा डेटा बाइट के दो टुकड़ों की तुलना करता है": ओवरसिम्प्लीफाइड, और बहुत बार यह सच नहीं है, क्योंकि एक्वाल्स (=) व्यवहार को कोलायत के साथ संशोधित किया जा सकता है, जिससे वर्ण वर्गों की तुलना वर्णों से की जा सकती है। उदाहरण के लिए dev.mysql.com/doc/refman/5.0/en/charset-collate.html (MySQL) या sqlmag.com/blog/forcing-collation-where-clause-22-jun-2011 (SQL Server) देखें।
पीटर बी

11
यह सही उत्तर है। हमें पता है कि क्या LIKEकरता है, लेकिन यह उत्तर अजीब तरह से बताता है कि LIKEबिना उपयोग %या _वर्तमान का उपयोग करना बिल्कुल भी समान नहीं है= । आपका उत्तर एक हजार तक प्राप्त हो सकता है।
रिनोगो

1
@ सच यह सच नहीं हो सकता। यदि मेरे वर्चर फ़ील्ड में मान शामिल है 'AbCdEfG', और मैं करता हूं WHERE MyCol = 'abcdefg', तो मुझे अभी भी वह पंक्ति वापस मिल गई है, भले ही वे स्पष्ट रूप से बाइट-बाय-बाइट नहीं हैं
किप

1
पीटरबी और @ किप दोनों अच्छे अंक जुटाते हैं। मैंने अपने जवाब में सुधार करने की कोशिश की है कि यह समझाने की कोशिश की गई है कि कैसे टकराव इन ऑपरेटरों को प्रभावित करता है।
मार्क ई। हासे

2
यह अब सच नहीं लगता: set charset latin1; SELECT 'ä' = 'ae' COLLATE latin1_german2_ci;0 देता है, और SELECT 'ä' LIKE 'ae' COLLATE latin1_german2_ci;0 भी देता है।
जोंक

170

बराबर (=) ऑपरेटर "तुलना ऑपरेटर समानता के लिए दो मूल्यों की तुलना करता है।" दूसरे शब्दों में, SQL कथन में, यह तब तक सही नहीं होगा जब तक कि समीकरण के दोनों पक्ष समान न हों। उदाहरण के लिए:

SELECT * FROM Store WHERE Quantity = 200;

LIKE ऑपरेटर "एक पैटर्न मैच तुलना को लागू करता है" जो वाइल्ड-कार्ड वर्णों वाले पैटर्न स्ट्रिंग के विरुद्ध एक स्ट्रिंग मान से मेल खाने का प्रयास करता है। उदाहरण के लिए:

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

आमतौर पर LIKE का उपयोग केवल स्ट्रिंग्स और इक्वल्स के साथ किया जाता है (मेरा मानना ​​है) तेज है। समान ऑपरेटर वाइल्ड-कार्ड वर्णों को शाब्दिक वर्णों के रूप में मानते हैं। लौटे परिणामों में अंतर इस प्रकार है:

SELECT * FROM Employees WHERE Name = 'Chris';

तथा

SELECT * FROM Employees WHERE Name LIKE 'Chris';

समान परिणाम लौटाएगा, हालांकि LIKE का उपयोग करना आमतौर पर एक पैटर्न मैच के रूप में अधिक समय लेगा। तथापि,

SELECT * FROM Employees WHERE Name = 'Chris%';

तथा

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

विभिन्न परिणामों को लौटाएगा, जहां "=" परिणामों का उपयोग करके "क्रिस%" के साथ केवल परिणाम प्राप्त होता है और LIKE ऑपरेटर "क्रिस" के साथ कुछ भी शुरू करेगा।

उम्मीद है की वो मदद करदे। कुछ अच्छी जानकारी यहाँ मिल सकती है


108
मैं इस धारणा के अंतर्गत हूं कि ओपी जानता है कि कब LIKE का उपयोग करना है और कब उपयोग करना है =, वह सोच रहा है कि क्या कोई वाइल्डकार्ड मौजूद नहीं है जब कोई प्रदर्शन अंतर है। यह उत्तर संक्षेप में इस पर है लेकिन मुझे लगता है कि इस उत्तर का 95% वास्तव में प्रासंगिक नहीं है।
आउटलाव प्रोग्रामर

1
सच सच। मुझे यकीन नहीं है कि जब मैंने जवाब दिया तो सवाल वही था। अगर ऐसा था, तो मैंने उस हिस्से को याद नहीं किया, जिसने प्रदर्शन के बारे में पूछा था। अवलोकन के लिए धन्यवाद।
achinda99

9
यह उत्तर भयानक है। LIKE और '=' पूरी तरह से अलग-अलग ऑपरेटर हैं, लेकिन मामलों के कुछ छोटे सबसेट में समान व्यवहार करते हैं। पोस्टीरिटी की खातिर, कृपया शेष उत्तर यहां पढ़ें, या कम से कम google के लिए "mysql like" करने से पहले इसे मेमोरी में कर दें।
मार्क ई। हसे

3
दूसरी ओर, इस सवाल का जवाब मेरे पास था और मैंने इसके लिए गुगली दी। कभी-कभी यह उतना ही अच्छा होता है अगर कोई उत्तर सामग्री के रूप में किसी प्रश्न के शीर्षक का उत्तर देता है।
कोराथन

याद करने के लिए एक अच्छा विचार है जब आप चार और varchar2 का उपयोग कर रहे हैं। यदि आप चार की तुलना चार से करते हैं। डेटाबेस की तुलना करने से पहले पहले 'वैरिएबल' की लंबाई को दूसरे के समान करें। यदि आप char और varchar2 की तुलना करते हैं तो डेटाबेस कुछ नहीं करेगा। docs.oracle.com/cd/A64702_01/doc/server.805/a58236/c_char.htm
xild

18

यह प्रश्न 'एस' जैसे 'बनाम' = प्रदर्शन के लिए मेरा एक और उत्तर की कॉपी / पेस्ट है :

Mysql 5.5 का उपयोग करते हुए एक व्यक्तिगत उदाहरण: मेरे पास 2 तालिकाओं, 3 मिलियन पंक्तियों में से एक और 10 हजार पंक्तियों में से एक के बीच एक आंतरिक जुड़ाव था।

नीचे (कोई वाइल्डकार्ड) के रूप में एक सूचकांक पर एक का उपयोग करते समय, लगभग 30 सेकंड लग गए:

where login like '12345678'

'व्याख्या' का उपयोग कर मुझे मिलता है:

यहां छवि विवरण दर्ज करें

एक ही क्वेरी पर '=' का उपयोग करते समय, लगभग 0.1 सेकंड लगते हैं:

where login ='12345678'

'व्याख्या' का उपयोग कर मुझे मिलता है:

यहां छवि विवरण दर्ज करें

जैसा कि आप देख सकते हैं, likeसूचकांक की तलाश को पूरी तरह से रद्द कर दिया गया, इसलिए क्वेरी को 300 गुना अधिक समय लगा।


17

LIKEऔर =अलग हैं। LIKEवह है जो आप एक खोज क्वेरी में उपयोग करेंगे। यह वाइल्डकार्ड जैसे _(सरल चरित्र वाइल्डकार्ड) और %(मल्टी-कैरेक्टर वाइल्डकार्ड) को भी अनुमति देता है ।

= यदि आप सटीक मिलान चाहते हैं तो इसका उपयोग किया जाना चाहिए और यह तेज़ होगा।

यह साइट बताती है LIKE


11

एक अंतर - LIKE के साथ वाइल्डकार्ड का उपयोग करने की संभावना के अलावा - अनुगामी स्थानों में है: = ऑपरेटर अनुगामी स्थान को अनदेखा करता है, लेकिन LIKE नहीं करता है।


4
हालांकि यह MySQL और MS SQL के लिए सही है, यह PostgreSQL के लिए नहीं है।
ब्रूनो

10

डेटाबेस सिस्टम पर निर्भर करता है।

आम तौर पर कोई विशेष वर्ण नहीं होता, हां, = और LIKE समान हैं।

कुछ डेटाबेस सिस्टम, हालांकि, अलग-अलग ऑपरेटरों के साथ कोलाज सेटिंग्स को अलग-अलग तरीके से व्यवहार कर सकते हैं।

उदाहरण के लिए, MySQL में = स्ट्रिंग्स के साथ तुलना हमेशा डिफ़ॉल्ट रूप से केस-असंवेदनशील होती है, इसलिए विशेष वर्णों के बिना LIKE समान है। कुछ अन्य RDBMS के LIKE पर केस असंवेदनशील है जबकि = नहीं है।


क्या इस विषमता के लिए अवलोकन जैसा कुछ है?
गुमबो

9

इस उदाहरण के लिए हम इसे इस रूप में लेते हैं कि varcharcol इसमें शामिल नहीं है ''और इस कॉलम के खिलाफ कोई खाली सेल नहीं है

select * from some_table where varcharCol = ''
select * from some_table where varcharCol like ''

पहली पंक्ति में 0 पंक्ति आउटपुट होता है जबकि दूसरा पूरी सूची दिखाता है। = फ़िल्टर की तरह कार्य करते समय सख्ती से मिलान वाला मामला है। यदि फ़िल्टर का कोई मापदंड नहीं है, तो हर डेटा मान्य है।

जैसे - अपने उद्देश्य के आधार पर थोड़ा धीमी गति से काम करता है और इसका मतलब है कि varchar और इसी तरह के डेटा के साथ उपयोग करना।


6

यदि आप एक सटीक मिलान खोजते हैं, तो आप =, और LIKE दोनों का उपयोग कर सकते हैं।

इस मामले में "=" का उपयोग करना थोड़ा तेज है (सटीक मिलान के लिए खोज करना) - आप SQL सर्वर मैनेजमेंट स्टूडियो में एक ही बार दो बार एक ही क्वेरी होने के बाद, "=", एक बार "LIKE" और फिर "क्वेरी" / "वास्तविक निष्पादन योजना शामिल करें" का उपयोग कर।

दो प्रश्नों को निष्पादित करें और आपको अपने परिणाम दो बार देखने चाहिए, साथ ही दो वास्तविक निष्पादन योजनाएं। मेरे मामले में, वे 50% बनाम 50% विभाजित थे, लेकिन "=" निष्पादन योजना की एक छोटी "अनुमानित सबट्री कॉस्ट" है (जब आप बाएं-सबसे "सिलेक्ट" बॉक्स पर होवर करते हैं) - लेकिन फिर, यह वास्तव में है बहुत बड़ा अंतर नहीं है।

लेकिन जब आप अपनी LIKE अभिव्यक्ति में वाइल्डकार्ड के साथ खोज शुरू करते हैं, तो खोज प्रदर्शन कम हो जाएगा। खोज "LIKE मिल%" अभी भी काफी तेज हो सकता है - SQL सर्वर उस कॉलम पर एक इंडेक्स का उपयोग कर सकता है, यदि कोई है। "LIKE% एक्सप्रेशन%" की खोज बहुत ही धीमी है, क्योंकि SQL सर्वर इस खोज को पूरा करने का एकमात्र तरीका पूर्ण टेबल स्कैन कर सकता है। इसलिए अपने LIKE से सावधान रहें!

न घुलनेवाली तलछट


-1 के रूप में, यह हमेशा एक छोटा सा तेज नहीं है। यदि स्तंभ%% का उपयोग करके अनुक्रमित किया जाता है तो% परिमाण के आदेशों के कुछ जोड़े हैं। वास्तव में उनके नमक के मूल्य के किसी भी कोड मानकों पर कठोर दिशा-निर्देश होंगे कि कब और कैसे किसी मिकी माउस डेटाबेस की तुलना में किसी बड़े पर उपयोग नहीं किया जाए।
क्रूज

1
मैंने कभी नहीं कहा कि यह सभी मामलों के लिए एक छोटा सा धीमा होगा - मैंने कहा कि यदि आप एक एक्जिट मैच के लिए खोज करते हैं तो यह एक छोटा सा धीमा होगा। Couse में, एक LIKE के साथ सर्च करना और वाइल्डकार्ड्स का उपयोग करना, विशेष रूप से आपके खोज आइटम की शुरुआत और अंत में, बहुत धीमी है, इस बारे में कोई संदेह नहीं है।
marc_s

और हाँ, मैं सहमत हूँ - किसी के पास स्पष्ट दिशा-निर्देश होना चाहिए कि LIKE का उपयोग कब करना है या नहीं (केवल जब आप वाइल्डकार्ड के साथ खोजना चाहते हैं)। लेकिन फिर - सिद्धांत में, सिद्धांत और व्यवहार में कोई अंतर नहीं है, लेकिन व्यवहार में .......
marc_s

6

जब आप रन टाइम पर क्वेरी का निर्माण करते हैं तो स्ट्रिंग में वाइल्डकार्ड और विशेष वर्णों के टकराव से बचा जाता है।

यह प्रोग्रामर के जीवन को सभी विशेष वाइल्डकार्ड वर्णों से बचने के लिए आसान नहीं बनाता है जो कि LIKE क्लॉज में खिसक सकते हैं और इच्छित परिणाम नहीं उत्पन्न कर सकते हैं। आखिरकार, = 99% उपयोग मामला परिदृश्य है, यह हर बार उन्हें बचने के लिए एक दर्द होगा।

90 के दशक में आँखें घुमाता है

मुझे यह भी संदेह है कि यह थोड़ा धीमा है, लेकिन मुझे संदेह है कि यदि पैटर्न में कोई वाइल्डकार्ड नहीं हैं तो यह महत्वपूर्ण है।


6

प्रदर्शन के संबंध में मूल प्रश्न को संबोधित करने के लिए, यह सूचकांक उपयोग के लिए नीचे आता है । जब एक साधारण टेबल स्कैन होता है, तो "LIKE" और "=" समान होते हैं । जब इंडेक्स शामिल होते हैं, तो यह निर्भर करता है कि LIKE क्लॉज कैसे बनता है। अधिक विशेष रूप से, वाइल्डकार्ड (ओं) का स्थान क्या है?


निम्नलिखित को धयान मे रखते हुए:

CREATE TABLE test(
    txt_col  varchar(10) NOT NULL
)
go

insert test (txt_col)
select CONVERT(varchar(10), row_number() over (order by (select 1))) r
  from master..spt_values a, master..spt_values b
go

CREATE INDEX IX_test_data 
    ON test (txt_col);
go 

--Turn on Show Execution Plan
set statistics io on

--A LIKE Clause with a wildcard at the beginning
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '%10000'
--Results in
--Table 'test'. Scan count 3, logical reads 15404, physical reads 2, read-ahead reads 15416, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index SCAN is 85% of Query Cost

--A LIKE Clause with a wildcard in the middle
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '1%99'
--Results in
--Table 'test'. Scan count 1, logical reads 3023, physical reads 3, read-ahead reads 3018, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost for test data, but it may result in a Table Scan depending on table size/structure

--A LIKE Clause with no wildcards
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO

--an "=" clause = does Index Seek same as above
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col = '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO


DROP TABLE test

"=" बनाम "LIKE" का उपयोग करते समय क्वेरी योजना के निर्माण में भी नगण्य अंतर हो सकता है।


4

वाइल्डकार्ड के अलावा, =AND के बीच का अंतर LIKESQL सर्वर के दोनों प्रकार और कॉलम प्रकार पर निर्भर करेगा।

इस उदाहरण को लें:

CREATE TABLE testtable (
  varchar_name VARCHAR(10),
  char_name CHAR(10),
  val INTEGER
);

INSERT INTO testtable(varchar_name, char_name, val)
    VALUES ('A', 'A', 10), ('B', 'B', 20);

SELECT 'VarChar Eq Without Space', val FROM testtable WHERE varchar_name='A'
UNION ALL
SELECT 'VarChar Eq With Space', val FROM testtable WHERE varchar_name='A '
UNION ALL
SELECT 'VarChar Like Without Space', val FROM testtable WHERE varchar_name LIKE 'A'
UNION ALL
SELECT 'VarChar Like Space', val FROM testtable WHERE varchar_name LIKE 'A '
UNION ALL
SELECT 'Char Eq Without Space', val FROM testtable WHERE char_name='A'
UNION ALL
SELECT 'Char Eq With Space', val FROM testtable WHERE char_name='A '
UNION ALL
SELECT 'Char Like Without Space', val FROM testtable WHERE char_name LIKE 'A'
UNION ALL
SELECT 'Char Like With Space', val FROM testtable WHERE char_name LIKE 'A '
  • MS SQL सर्वर 2012 का उपयोग करते हुए, अनुरेखण रिक्त स्थान की तुलना में अनदेखा किया जाएगा, सिवाय इसके कि LIKEजब स्तंभ प्रकार हो VARCHAR

  • MySQL 5.5 का उपयोग करते हुए, अनुगामी रिक्त स्थान को अनदेखा किया जाएगा =, लेकिन LIKEदोनों के साथ CHARऔर के लिए नहीं VARCHAR

  • PostgreSQL 9.1 का उपयोग करते हुए , रिक्त स्थान दोनों के साथ महत्वपूर्ण हैं =और LIKEउपयोग कर रहे हैं VARCHAR, लेकिन CHAR( प्रलेखन देखें ) के साथ नहीं ।

    साथ व्यवहार LIKEभी भिन्न होता है CHAR

    ऊपर के समान डेटा का उपयोग करके CAST, कॉलम नाम पर एक स्पष्ट का उपयोग करने से भी फर्क पड़ता है :

    SELECT 'CAST none', val FROM testtable WHERE char_name LIKE 'A'
    UNION ALL
    SELECT 'CAST both', val FROM testtable WHERE
        CAST(char_name AS CHAR) LIKE CAST('A' AS CHAR)
    UNION ALL
    SELECT 'CAST col', val FROM testtable WHERE CAST(char_name AS CHAR) LIKE 'A'
    UNION ALL
    SELECT 'CAST value', val FROM testtable WHERE char_name LIKE CAST('A' AS CHAR)

    यह केवल "CAST दोनों" और "CAST col" के लिए पंक्तियाँ लौटाता है।


2

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

सादर...


1

वास्तव में यह नीचे आता है कि आप क्या करना चाहते हैं। यदि आपका मतलब एक सटीक मिलान है तो उपयोग करें =। अगर आपका मतलब फजी मैच है, तो LIKE का उपयोग करें। यह कहना कि आपका मतलब क्या है आमतौर पर कोड के साथ एक अच्छी नीति है।


1

ओरेकल में, बिना वाइल्डकार्ड वाले एक 'जैसे' एक ही परिणाम को 'बराबर' के रूप में लौटाएगा, लेकिन अतिरिक्त प्रसंस्करण की आवश्यकता हो सकती है। टॉम कायटे के अनुसार , ओरेकल शाब्दिक का उपयोग करते समय बिना वाइल्डकार्ड के एक 'जैसे' के साथ व्यवहार करेगा, लेकिन बाइंड चर का उपयोग करते समय नहीं।


0

=और LIKEऐसा ही नहीं है;

  1. = सटीक स्ट्रिंग से मेल खाता है
  2. LIKE एक स्ट्रिंग से मेल खाता है जिसमें वाइल्डकार्ड (%) हो सकता है

2
अपर्याप्त उत्तर

यह वाइल्डकार्ड के बिना इस्तेमाल किया जा सकता है। इस सवाल ने समान मामलों के लिए अंतर पूछा।
एम-रज़वी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.