Porównaj różnice wydajności T-SQL między i "<' '>" operator?

Question

Próbowałem wyszukiwać przez wyszukiwarki, MSDN itp. ale nic nie może. Przepraszam, jeśli wcześniej zostało to zadane. Czy istnieje różnica w wydajności między słowami kluczowymi T-SQL "Between" lub operatorami porównania?

Answer 1

Możesz to łatwo sprawdzić, sprawdzając plany zapytań w obu sytuacjach. Nie znam żadnej różnicy. Istnieje jednak logiczna różnica między BETWEEN a "<" i ">" ... BETWEEN is inclusive. Odpowiada to "< =" i "=>".

Answer 2

Te dwa operatory, które są tutaj porównywane, różnią się zasadniczo, dlatego też generowane plany wykonania prawdopodobnie będą inne (choć nie gwarantowane).

Czynnikiem determinującym jest rozkład danych (selektywność) kolumny, do której stosowane są operatory porównania. To wraz ze statystykami będzie dyktować, czy indeks jest lub nie jest używany itp.

Mam nadzieję, że to ma sens.

Answer 3

w rzeczywistości. Próbuję tylko sprawdzić między niektórymi z moich danych. BETWEEN jest równoważne "> =" i "<". Na przykład: od '05/01/2010 'do '05/30/2010': Dane będą dostępne tylko między 5/1/2010 00:00:00 a 5/29/2010 23:59:59. Spróbuj zapytać o tabelę za pomocą polecenia "Sortuj według [TimeField]", a zobaczysz wynik.

Answer 4

Byłem również zainteresowany, czy występuje różnica w wydajności, gdy użyłem (> = i < =) w porównaniu do użycia słowa kluczowego między. (Pochodzę z tła dotnetowego i lubię operatory stylów> =).
Oto skrypt użyłem:

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'; 

Wyniki były następujące:

Metoda 1: 140 ms

Metoda 2: 70 ms

Wygląda więc na to, że Wydajność jest lepsza dzięki użyciu między.

Answer 5

Uwielbiam, gdy ludzie dają kod do wykonania własnych testów, musisz wykonać większy test podzestawu/powtórzenia, aby uwzględnić indeksy załadowane do pamięci, itp., Zanim jednak wyciągniesz wnioski. Oto ten sam kod z większym stole i 10 iteracje

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 

daje bardzo inny zestaw wyników:

--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 

powiedziałbym z tego (jeszcze dość nienaukowe) testy, nie ma dużej różnicy tak czy inaczej.

Answer 6

silnik Zapytanie przekształca się >= i <= (przyjrzeć planu kwerend), więc w praktyce są one identyczne i teoretycznie >= <= jest szybciej, ponieważ silnik nie będzie musiał tłumaczyć. Życzymy powodzenia, zauważając jednak różnicę.

używam między każdym razie uważam, że to brzmi łatwiejsze

bardzo złożonych zapytań/zagnieżdżonych widoki z licznymi między porównaniem może korzystać ze zmieniających się >= <= ponieważ może to potencjalnie zapobiec timeoutów optymalizacji poprzez skrócenie czasu spędzanego na refactoring zapytania (tylko teoria, niesprawdzona przeze mnie & Nigdy tego nie zauważyłem)