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

Question

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

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

Answer 1

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

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

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

LIKE एक स्ट्रिंग ऑपरेटर है जो चरित्र द्वारा वर्णित करता है।

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

प्रेरित उदाहरण

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

प्रति SQL मानक की तरह एक प्रति चरित्र के आधार पर मिलान निष्पादित करता है, इस प्रकार यह परिणाम = तुलना ऑपरेटर से अलग उत्पादन कर सकते हैं:

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 मैनुअल के इस पृष्ठ को स्ट्रिंग तुलना फ़ंक्शन, और = पर चर्चा नहीं की गई है, जिसका अर्थ है कि = कड़ाई से स्ट्रिंग तुलना फ़ंक्शन नहीं है।

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

SQL Standard § 8.2 का वर्णन करता है = कैसे तुलना तार:

दो चरित्र तार की तुलना इस प्रकार निर्धारित किया जाता है:

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

बी) एक्स और वाई की तुलना का परिणाम कोटिंग अनुक्रम सीएस द्वारा दिया गया है।

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

(जोर जोड़ा।)

इसका क्या मतलब है? इसका मतलब है कि तारों की तुलना करते समय, = ऑपरेटर वर्तमान संयोजन के आसपास सिर्फ एक पतला आवरण है। एक संयोजन एक पुस्तकालय है जिसमें स्ट्रिंग की तुलना करने के लिए विभिन्न नियम हैं। (जो कारण है कि यह "बाइनरी" कहा जाता है - यह तार के लिए किसी भी विशेष अर्थ नहीं देता है)

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); 
} 

यह विशेष रूप से मिलान बाइट-दर-बाइट तुलना करने के लिए होता है: यहाँ a binary collation from MySQL का एक उदाहरण है। अन्य collations अधिक उन्नत तुलना प्रदान कर सकते हैं।

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

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

SQL Standard § 8.5 का वर्णन करता है LIKE कैसे तुलना तार:

< विधेय अगर वहाँ सबस्ट्रिंग में एम की एक विभाजन मौजूद है >

M LIKE P

सच है ऐसी है कि:

i) एम का एक सबस्ट्रिंग 0 या मो का अनुक्रम है फिर से संगत < चरित्र प्रतिनिधित्व > एम और प्रत्येक < चरित्र एम 0 का प्रतिनिधित्व > एम एक बिल्कुल सबस्ट्रिंग का हिस्सा है।

ii) यदि मैं-वें पी की सबस्ट्रिंग विनिर्देशक एक मनमाना चरित्र विनिर्देशक है, एम के आई-वें-स्ट्रिंग किसी एक < चरित्र प्रतिनिधित्व > है।

iii) आई-वें पी की सबस्ट्रिंग विनिर्देशक एक मनमाना स्ट्रिंग विनिर्देशक है, तो एम के आई-वें-स्ट्रिंग 0 या अधिक < चरित्र प्रतिनिधित्व > रों के किसी भी क्रम है।

iv) आई-वें पी की सबस्ट्रिंग विनिर्देशक का न तो कोई मनमाना चरित्र विनिर्देशक है और न ही एक मनमाना स्ट्रिंग विनिर्देशक है, तो तो एम के आई-वें-स्ट्रिंग कि सबस्ट्रिंग विनिर्देशक के बराबर collating अनुक्रम के अनुसार है <की भविष्यवाणी के बिना, < स्पेस > एम के पात्रों के बिना, और विनिर्देशक के समान लंबाई के समान है।

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

(जोर जोड़ा।)

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

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

निष्कर्ष

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

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

Answer 2

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

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

90 के दशक

मैं भी संदेह है कि यह एक छोटा सा धीमी है, लेकिन मुझे शक है यह महत्वपूर्ण है कि अगर वहाँ पैटर्न में कोई वाइल्डकार्ड हैं पर रोल आँखें।

Answer 3

= और LIKE समान नहीं है; अलग संभावना की तरह साथ वाइल्डकार्ड का उपयोग करने के लिए से - -

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

Answer 4

एक अंतर यह मेल खाता से मेल खाता है रिक्त स्थान अनुगामी में है: = ऑपरेटर पीछे की जगह को अनदेखा करता है, लेकिन पसंद नहीं करता है।

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

This site explains LIKE

Answer 8

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

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

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

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

मार्क

Answer 9

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

सादर ...

Answer 10

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

SELECT * FROM Store WHERE Quantity = 200; 

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

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

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

SELECT * FROM Employees WHERE Name = 'Chris'; 

और

SELECT * FROM Employees WHERE Name LIKE 'Chris'; 

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

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

और

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

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

उम्मीद है कि मदद करता है। कुछ अच्छी जानकारी here मिल सकती है।

Answer 11

प्रदर्शन के संबंध में मूल प्रश्न को संबोधित करने के लिए, यह सूचकांक उपयोग पर आता है। जब एक साधारण टेबल स्कैन होता है, तो "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 

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

---

निम्नलिखित पर विचार करें।

Answer 12

ओरेकल में, कोई वाइल्डकार्ड वाले 'जैसे' समान परिणाम को 'बराबर' के रूप में वापस कर देगा, लेकिन अतिरिक्त प्रसंस्करण की आवश्यकता हो सकती है। According to Tom Kyte, ओरेकल अक्षरों का उपयोग करते समय 'बराबर' के साथ 'समान' के साथ 'समान' के रूप में व्यवहार करेगा, लेकिन बाध्य चर का उपयोग करते समय नहीं।

Answer 13

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

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

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 Server 2012 का उपयोग करना, पीछे वाले स्पेस, की तुलना में नजरअंदाज कर दिया जाएगा LIKE साथ छोड़कर जब स्तंभ प्रकार VARCHAR है।

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

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

  LIKE के साथ व्यवहार CHAR के साथ भी भिन्न है।

  उपर दिए गए डेटा का उपयोग करना, एक स्पष्ट CAST स्तंभ नाम also makes a difference पर का उपयोग कर: "कास्ट दोनों" और "कास्ट col" के लिए

  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) 
  

  यह केवल रिटर्न पंक्तियों।

Answer 14

इस उदाहरण हम दी गई कि varcharcol '' शामिल नहीं है के लिए इसे ले और इस स्तंभ

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

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

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

एक व्यक्तिगत उदाहरण mysql 5.5 का उपयोग कर:

Answer 15

यह एक कॉपी/प्रश्न SQL 'like' vs '=' performance के लिए मेरा एक और जवाब का पेस्ट है मैं 2 टेबल, 3 लाख पंक्तियों में से एक और 10 हजार पंक्तियों में से एक के बीच एक आंतरिक में शामिल होने के लिए किया था ।

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

where login like '12345678' 

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

जब एक का उपयोग कर '=' एक ही प्रश्न पर, इसमें लगभग 0.1 सेकंड लग गए:

where login ='12345678' 

'एक्सप' का उपयोग करना lain 'मैं मिलता है:

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