SQL 'जैसे' बनाम '=' प्रदर्शन

Question 1

यह सवाल मुझे क्या सोच रहा है के चारों ओर स्कर्ट है, लेकिन जवाब बिल्कुल इसे संबोधित नहीं करते हैं।

ऐसा लगता है कि सामान्य रूप से '=' वाइल्डकार्ड का उपयोग करते समय 'जैसे' से अधिक तेज होता है। यह पारंपरिक ज्ञान प्रतीत होता है। हालाँकि, मान लीजिए कि मेरे पास एक स्तंभ है जिसमें सीमित संख्या में विभिन्न निश्चित, हार्डकोड, varchar आइडेंटिफ़ायर हैं, और मैं उनमें से किसी एक से मेल खाती सभी पंक्तियों का चयन करना चाहता हूं:

select * from table where value like 'abc%'

तथा

select * from table where value = 'abcdefghijklmn'

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

यह एक सामान्य, अकादमिक प्रश्न के रूप में अभिप्रेत है, और इसलिए इस पर कोई फर्क नहीं पड़ता कि कौन सा DB है, लेकिन यह SQL Server 2005 का उपयोग कर उत्पन्न हुआ।

Question 2

Https://web.archive.org/web/20150209022016/http://myitforum.com/cs2/blogs/jnelson/archive/2007/11/16/108354.aspx देखें

वहां से बोली:

LIKE के साथ इंडेक्स के उपयोग के नियम इस तरह से शिथिल हैं:

यदि आपके फ़िल्टर मानदंड = का उपयोग करता है और फ़ील्ड अनुक्रमित है, तो सबसे अधिक संभावना है कि यह INDEX / CLUSTEREDEXEXEK का उपयोग करेगा

यदि आपके फ़िल्टर मापदंड LIKE का उपयोग करते हैं, बिना वाइल्डकार्ड के साथ (जैसे अगर आपके पास एक वेब रिपोर्ट में पैरामीटर था कि COULD में एक% है लेकिन आप इसके बजाय पूर्ण स्ट्रिंग का उपयोग करते हैं), तो यह सूचकांक का उपयोग करने के लिए # 1 के रूप में संभावना है। बढ़ी हुई लागत लगभग कुछ भी नहीं है।

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

फिर भी, यदि आपके फ़िल्टर मापदंड LIKE का उपयोग करते हैं, लेकिन एक STRING FIRST के साथ शुरू होता है और कहीं-कहीं वाइल्डकार्ड हैं (जैसा कि Name0 LIKE 'COMP% ER' में), तो SQL केवल पंक्तियों को जल्दी से उपयोग करने के लिए एक INDEX SEEK का उपयोग कर सकता है जिसमें पहले समान शुरुआती अक्षर, और फिर एक सटीक मिलान के लिए उन पंक्तियों के माध्यम से देखें।

(यह भी ध्यान रखें, SQL इंजन अभी भी एक अनुक्रमणिका का उपयोग नहीं कर सकता है जिस तरह से आप उम्मीद कर रहे हैं, यह इस बात पर निर्भर करता है कि आपकी क्वेरी में क्या चल रहा है और आप किन तालिकाओं में शामिल हो रहे हैं। SQL इंजन आपके पुन: लिखने का अधिकार सुरक्षित रखता है। इस तरह से डेटा प्राप्त करने के लिए थोड़ा क्वेरी करें जो यह सोचता है कि यह सबसे कुशल है और इसमें INDEX SCEK के बजाय INDEX SCAN शामिल हो सकता है)

Question 3

यह एक औसत दर्जे का अंतर है।

निम्नलिखित चलाएँ:

Create Table #TempTester (id int, col1 varchar(20), value varchar(20))
go

INSERT INTO #TempTester (id, col1, value)
VALUES
(1, 'this is #1', 'abcdefghij')
GO

INSERT INTO #TempTester (id, col1, value)
VALUES
(2, 'this is #2', 'foob'),
(3, 'this is #3', 'abdefghic'),
(4, 'this is #4', 'other'),
(5, 'this is #5', 'zyx'),
(6, 'this is #6', 'zyx'),
(7, 'this is #7', 'zyx'),
(8, 'this is #8', 'klm'),
(9, 'this is #9', 'klm'),
(10, 'this is #10', 'zyx')
GO 10000

CREATE CLUSTERED INDEX ixId ON #TempTester(id)CREATE CLUSTERED INDEX ixId ON #TempTester(id)

CREATE NONCLUSTERED INDEX ixTesting ON #TempTester(value)

फिर:

SET SHOWPLAN_XML ON

फिर:

SELECT * FROM #TempTester WHERE value LIKE 'abc%'

SELECT * FROM #TempTester WHERE value = 'abcdefghij'

परिणामी निष्पादन योजना आपको दिखाती है कि पहले ऑपरेशन की लागत, LIKEतुलना, तुलना की तुलना में लगभग 10 गुना अधिक महंगा है =।

यदि आप एक =तुलना का उपयोग कर सकते हैं , तो कृपया ऐसा करें।

Question 4

आपको यह भी ध्यान रखना चाहिए कि उपयोग करते समय like, कुछ sql फ्लेवर इंडेक्स की उपेक्षा करेंगे, और यह प्रदर्शन को मार देगा। यह विशेष रूप से सच है यदि आप अपने उदाहरण की तरह "स्टार्ट विथ" पैटर्न का उपयोग नहीं करते हैं।

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

यह कहा जा रहा है, "पैटर्न के साथ शुरू होता है" और sql सर्वर में अनुकूलित होता है। यह तालिका सूचकांक का उपयोग करेगा । EF 4.0 ने इसी कारण से इसके likeलिए स्विच किया StartsWith।

Question 5

यदि valueएकतरफा है, तो दोनों तालिका-स्कैन में परिणाम करते हैं। इस परिदृश्य में प्रदर्शन अंतर नगण्य होगा।

यदि valueअनुक्रमित किया जाता है, जैसा कि डैनियल अपनी टिप्पणी में बताते हैं, तो =एक अनुक्रमणिका लुकअप में परिणाम होगा जो ओ (लॉग एन) प्रदर्शन है। अनुक्रमणिका के आंशिक स्कैन के परिणामस्वरूप LIKE होगा (सबसे अधिक संभावना है - यह कि यह कितना चयनात्मक है) पर निर्भर करता है >= 'abc'और < 'abd'इसके लिए अधिक प्रयास की आवश्यकता होगी =।

ध्यान दें कि मैं यहां SQL सर्वर की बात कर रहा हूं - सभी DBMS LIKE के साथ अच्छे नहीं होंगे।

Question 6

आप गलत सवाल पूछ रहे हैं। डेटाबेस में ऑपरेटर का प्रदर्शन नहीं है जो मायने रखता है, हमेशा अभिव्यक्ति की SARGability , और समग्र क्वेरी की coverability है। ऑपरेटर का प्रदर्शन अपने आप में काफी हद तक अप्रासंगिक है।

तो, SARGability के संदर्भ में कैसे करें LIKEऔर =तुलना करें? LIKE, जब एक अभिव्यक्ति के साथ प्रयोग किया जाता है जो एक स्थिरांक के साथ शुरू नहीं होता है (उदाहरण के लिए। जब इस्तेमाल किया जाता है LIKE '%something') परिभाषा गैर-सरगाबेल द्वारा होता है। लेकिन यह बनाता है =या LIKE 'something%'SARGable? नहीं। SQL प्रदर्शन के बारे में किसी भी प्रश्न के साथ उत्तर पाठ की क्वेरी के साथ नहीं है, लेकिन स्कीमा तैनात है। यदि कोई सूचकांक उन्हें संतुष्ट करने के लिए मौजूद है तो ये अभिव्यक्ति SARGable हो सकती है।

तो, सच तो यह है, कहा जा वहाँ के बीच छोटे मतभेद हैं =और LIKE। लेकिन यह पूछना कि क्या SQL में एक ऑपरेटर या अन्य ऑपरेटर 'तेज' है, यह पूछने की तरह है कि 'क्या तेज होता है, एक लाल कार या एक नीली कार?' आपको ईबे से इंजन के आकार और वेजिकल वेट के बारे में सवाल पूछने चाहिए, रंग के बारे में नहीं ... संबंधपरक तालिकाओं के अनुकूलन के बारे में सवालों के जवाब के लिए, देखने की जगह आपके सूचकांक और WHERE क्लॉज (और अन्य क्लॉस) में आपके भाव हैं, लेकिन आमतौर पर कहां से शुरू होता है)।

Question 7

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

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

where login like '12345678'

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

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

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

where login ='600009'

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

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

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

Question 8

शायद आप पूर्ण पाठ खोज के बारे में देख रहे हैं ।

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

Question 9

पहली चीजें पहले ,

वे हमेशा समान नहीं होते हैं

    select 'Hello' from dual where 'Hello  ' like 'Hello';

    select 'Hello' from dual where 'Hello  ' =  'Hello';

जब चीजें हमेशा समान नहीं होती हैं, तो उनके प्रदर्शन के बारे में बात करना उतना प्रासंगिक नहीं होता है।

यदि आप स्ट्रिंग्स और केवल चार चर पर काम कर रहे हैं, तो आप प्रदर्शन के बारे में बात कर सकते हैं। लेकिन आम तौर पर विनिमेय होने के नाते "और" = का उपयोग न करें।

जैसा कि आपने कई पदों (ऊपर और अन्य प्रश्नों) में देखा होगा, ऐसे मामलों में जब वे समान होते हैं जैसे कि पैटर्न मिलान (टकराव) के कारण धीमी गति होती है