T-SQL 사이의 성능 차이와 '<' '>'연산자를 비교해보십시오.

Question

검색 엔진, MSDN 등을 통해 검색을 시도했습니다. 그러나 아무것도 할 수 없다. 죄송합니다 전에 물어 본 경우. T-SQL "Between"키워드를 사용하거나 비교 연산자를 사용하는 것 사이에 성능 차이가 있습니까?

Answer 1

두 상황 모두에서 쿼리 계획을 확인하면 쉽게 확인할 수 있습니다. 내가 알고있는 차이가 없다. BETWEEN과 "<"과 ">"... 사이에는 논리적 인 차이가 있습니다. 둘 사이에 포함됩니다. "< ="및 "=>"과 동일합니다.

Answer 2

여기에서 서로 비교되는 두 연산자는 근본적으로 다르므로 생성 된 실행 계획도 (보장되지는 않지만) 다를 수 있습니다.

결정 요인은 비교 연산자가 적용되는 열의 데이터 분포 (선택도)입니다. 통계와 함께 색인이 사용되는지 여부가 결정됩니다.

희망이 있습니다.

Answer 3

실제로. 나는 내 데이터의 일부를 검증하려고 노력한다. BETWEEN은 "> ="및 "<"과 같습니다. 예 : '05/01/2010 '과 '05/30/2010'사이 : 2010 년 5 월 1 일 00:00:00부터 5/29/2010 23:59:59 사이의 데이터 만 가져옵니다. "Order [TimeField] desc"로 테이블을 쿼리하면 결과가 표시됩니다.

Answer 4

between 키워드를 사용했을 때와 비교했을 때 (> = 및 < =) 성능 차이가 있는지에 대해서도 관심이있었습니다. (저는 dotnet 배경에서 왔고> = 스타일 연산자와 비슷합니다).

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

방법 :

그래서이 나타납니다 (70) MS
여기 내가 사용하는 스크립트입니다 사이에 사용하면 성능이 향상됩니다.

Answer 5

사람들이 자신의 테스트를 수행하는 코드를 제공하면, 결론에 도달하기 전에 메모리에로드되는 인덱스를 고려하여 더 큰 하위 집합/반복 테스트를 수행해야합니다. 여기

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 

당신에게 결과의 매우 다른 세트를 제공합니다 같은 큰 테이블 코드 10 개의 반복이다 :

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

내가 (매우 비 과학적 여전히)이에서 말을 시험하지 많은 차이 어느쪽으로 든.

Answer 6

쿼리 엔진은 >=과 <= (쿼리 계획을 살펴 봅니다.)로 변환되므로 실제로는 동일하며 이론상으로는 엔진을 변환 할 필요가 없기 때문에 더 빠른 것입니다 (>= <=). 그래도 행운을 빌어 요.어쨌든간에 사용

, 나는이 잠재적으로 쿼리를 리팩토링에 소요되는 시간을 단축하여 최적화 시간 제한을 방지 할 수있는대로 >= <=로 변경 혜택을 누릴 수있는 비교 사이의 수많은로 쉽게

매우 복잡한 쿼리/중첩 된 뷰를 읽고 발견 (단지 이론, 나를 테스트 한 적이 &)