2009-05-28 27 views
12

मैंने खोज इंजन, एमएसडीएन, आदि के माध्यम से खोज करने की कोशिश की है। लेकिन कुछ भी नहीं कर सकता। माफ करना, अगर यह पहले भी पूछा गया है। क्या टी-एसक्यूएल "बीच" कीवर्ड या तुलना ऑपरेटरों का उपयोग करने के बीच कोई प्रदर्शन अंतर है?टी-एसक्यूएल के बीच और '<' '>' ऑपरेटर के प्रदर्शन अंतर की तुलना करें?

उत्तर

23

आप दोनों स्थितियों में क्वेरी योजनाओं की जांच करके इसे आसानी से देख सकते हैं। इसमें कोई फर्क नहीं पड़ता कि मुझे पता है। हालांकि BETWEEN और "<" और ">" के बीच एक तार्किक अंतर है ... BETWEEN समावेशी है। यह "< =" और "=>" के बराबर है।

+0

अच्छा बिंदु। एक सूक्ष्मता मैंने नहीं देखा था। –

1

दो ऑपरेटरों की तुलना एक दूसरे से की जा रही है, जो मूल रूप से अलग हैं और इसलिए क्यों उत्पन्न होने वाली निष्पादन योजनाएं अलग-अलग होने की संभावना है (हालांकि गारंटी नहीं है)।

निर्धारक कारक स्तंभ तुलना ऑपरेटरों में लागू किए गए डेटा वितरण (चयनात्मकता) है। आंकड़ों के साथ यह निर्देश देगा कि इंडेक्स है या नहीं। आदि

आशा है कि यह समझ में आता है।

+0

निश्चित नहीं है कि यह क्यों मतदान किया गया था। क्या जॉन ने कुछ गलत कहा था? कोई बहुत अच्छा महसूस नहीं कर रहा है? क्या किसी के भी पास कोई सुझाव है? – wcm

+0

मैंने मूल प्रश्न कभी नहीं बदला है। मैंने वोट भी नहीं दिया। –

+0

यह उत्तर मुझे समझ में आता है ... इसलिए यह नीचे वोट अजीब है – Michael

0

वास्तव में। मैं बस अपने कुछ डेटा के बीच सत्यापन करने की कोशिश करता हूं। BETWEEN "> =" और "<" के बराबर है। उदाहरण के लिए: '05/01/2010 'और '05/30/2010' के बीच: आपको केवल 5/1/2010 00:00:00 से 5/29/2010 23:59:59 के बीच डेटा प्राप्त होगा। "ऑर्डर बाय [टाइमफिल्ड] desc" के साथ अपनी तालिका से पूछें और आप परिणाम देखेंगे।

+3

नहीं यह गलत है। क्या आप सुनिश्चित हैं कि आपके पास डेटा है जो मिलीसेकंड में '5/30/2010 00: 00: 00.000' है? –

+0

यह विरोधाभास दस्तावेज है, जिसका अर्थ है कि यदि यह सच है तो यह एक बग है। मैं श्री स्मिथ से सहमत हूं कि डेटा शायद गलत है। –

0

मुझे इस बात का भी रूचि था कि जब मैं कीवर्ड के बीच उपयोग करने की तुलना में (> = और < =) का उपयोग करता हूं तो प्रदर्शन अंतर होता है या नहीं। (मैं एक डॉटनेट पृष्ठभूमि से आया हूं और> = स्टाइल ऑपरेटर की तरह)।

DECLARE 
    @Startdatetime datetime , 
    @Diff int = 0 , 
    @Addrowcount int = 1000; 

SET NOCOUNT ON; 

--Create a tempory table to perform our tests on 

CREATE TABLE dbo.perftest(id smallint NOT NULL 
             IDENTITY(1 , 1) 
             PRIMARY KEY , 
          mytext nvarchar(50)NOT NULL); 

--Now add some sample rows 

SET @Addrowcount = 1000; 

WHILE(@Addrowcount > 0) 

    BEGIN 

     INSERT INTO dbo.perftest(mytext) 
     VALUES('thetext'); 

     SET @Addrowcount = @Addrowcount - 1; 

    END; 

SELECT @Startdatetime = GETDATE(); 

-- do method 1 here 

SELECT mytext 
    FROM dbo.perftest 
    WHERE(id >= 100) 
    AND (id <= 900); 

--end method1 

SELECT @Diff = DATEDIFF(millisecond , @Startdatetime , GETDATE()); 

PRINT ':Method 1: ' + CAST(@Diff AS nvarchar(20)) + ' ms'; 

--reset start time 

SELECT @Startdatetime = GETDATE(); 

--do method2 here 

SELECT mytext 
    FROM dbo.perftest 
    WHERE id BETWEEN 100 
    AND 900; 

--end method2 

SELECT @Diff = DATEDIFF(millisecond , @Startdatetime , GETDATE()); 

PRINT ':Method 2: ' + CAST(@Diff AS nvarchar(20)) + ' ms'; 

परिणाम इस प्रकार थे:

विधि 1: 140 एमएस

विधि 2: 70 एमएस

तो यह है कि प्रतीत होता है
यहाँ स्क्रिप्ट मैं प्रयोग किया जाता है प्रदर्शन के बीच प्रदर्शन में सुधार किया गया है।

+0

यह सुनिश्चित नहीं है कि इस तरह का परीक्षण कितना वैध है ... मुझे लगता है कि किसी भी साधारण प्रोफ़ाइल परीक्षण के रूप में मान्य है, लेकिन यह ज्यादा नहीं कह रहा है। कैशिंग के आधार पर बहुत अलग हो सकता है (आपने केवल रिकॉर्ड्स जोड़े हैं) और उस समय कुछ भी नहीं चल रहा है (असली दुनिया सर्वर के विपरीत), और एक ही समय में सभी रिकॉर्ड जोड़े जा रहे हैं, बनाम कई पृष्ठों/समय पर खंडित किया जा रहा है । – eselk

1

जब लोग आपके स्वयं के परीक्षण करने के लिए कोड देते हैं तो प्यार करें, आपको इंडेक्स को स्मृति में लोड होने के लिए खाते में बड़े सबसेट/बार-बार परीक्षण करने की आवश्यकता है ... हालांकि निष्कर्ष पर कूदने से पहले। यहाँ एक बड़ी मेज के साथ एक ही कोड और 10 पुनरावृत्तियों

DECLARE 
    @Startdatetime datetime , 
    @Diff int = 0 , 
    @Addrowcount int = 1000 , 
    @ptr int = 1; 


SET NOCOUNT ON; 

--Create a tempory table to perform our tests on 
DROP TABLE dbo.perftest 

CREATE TABLE dbo.perftest(id int NOT NULL 
             IDENTITY(1 , 1) 
             PRIMARY KEY , 
          mytext nvarchar(50)NOT NULL); 

--Now add some sample rows 

SET @Addrowcount = 20000; 

WHILE(@Addrowcount > 0) 

    BEGIN 

     INSERT INTO dbo.perftest(mytext) 
     VALUES('thetext'); 

     SET @Addrowcount = @Addrowcount - 1; 

    END; 

WHILE @ptr < 10 -- do this a few times to account for indexes being loaded into memory 

BEGIN 

    SELECT @Startdatetime = GETDATE(); 

    -- do method 1 here 

    SELECT mytext 
     FROM dbo.perftest 
     WHERE(id >= (100 + (@ptr * 1000))) 
     AND (id <= (500 + (@ptr * 1000))); 

    --end method1 

    SELECT @Diff = DATEDIFF(millisecond , @Startdatetime , GETDATE()); 

    PRINT ':Method 1: ' + CAST(@Diff AS nvarchar(20)) + ' ms'; 

    --reset start time 

    SELECT @Startdatetime = GETDATE(); 

    --do method2 here 

    SELECT mytext 
     FROM dbo.perftest 
     WHERE id BETWEEN (300 + (@ptr * 1000)) 
     AND (800 + (@ptr * 1000)); 

    --end method2 

    SELECT @Diff = DATEDIFF(millisecond , @Startdatetime , GETDATE()); 

    PRINT ':Method 2: ' + CAST(@Diff AS nvarchar(20)) + ' ms'; 

    SET @ptr = @ptr + 1 

END 

आप परिणामों का एक बहुत अलग सेट देता है:

--Method 1 -- 10 ms 
--Method 2 -- 33 ms 
--Method 1 -- 40 ms 
--Method 2 -- 26 ms 
--Method 1 -- 23 ms 
--Method 2 -- 23 ms 
--Method 1 -- 13 ms 
--Method 2 -- 16 ms 
--Method 1 -- 13 ms 
--Method 2 -- 20 ms 
--Method 1 -- 6 ms 
--Method 2 -- 16 ms 
--Method 1 -- 26 ms 
--Method 2 -- 16 ms 
--Method 1 -- 13 ms 
--Method 2 -- 13 ms 
--Method 1 -- 16 ms 
--Method 2 -- 13 ms 

मैं (अब भी बहुत अवैज्ञानिक) इस से कह सकते हैं कि परीक्षण, बहुत ज्यादा नहीं फर्क किसी भी तरह से।

4

क्वेरी इंजन के बीच में >= और <= (क्वेरी योजना पर एक नज़र डालें) में परिवर्तित कर देती व्यवहार में वे समान हैं और सिद्धांत में >= <= क्योंकि तेजी से इंजन का अनुवाद करने के लिए नहीं होगा है। यद्यपि एक अंतर को ध्यान में रखते हुए शुभकामनाएं।

मैं के बीच वैसे भी उपयोग करते हैं, मैं इसे तुलना के बीच कई के साथ आसान

बहुत जटिल प्रश्न/नेस्ट विचारों पढ़ता >= <= में परिवर्तित करने से लाभ हो सकता है के रूप में इस संभावित समय क्वेरी पुनर्रचना पर खर्च को कम करके अनुकूलन समय समाप्ति तक नहीं पहुंच पाएंगे लगता है (केवल एक सिद्धांत, मेरे द्वारा untested & मैंने इसे कभी नहीं देखा है)

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