比較T-SQL與'<' '>'運算符的性能差異？

Question

我試過搜索引擎，MSDN等。但不能任何東西。對不起，如果之前已經問過。使用T-SQL「Between」關鍵字還是使用比較運算符有什麼不同？

Answer 1

通過檢查兩種情況下的查詢計劃，您可以輕鬆檢查到這一點。我所知道的沒有區別。 BETWEEN和「<」之間有一個邏輯上的區別，「>」... BETWEEN是包容性的。它相當於「< =」和「=>」。

Answer 2

在這裏相互比較的兩個運營商是根本不同的，因此生成的執行計劃也可能不同（儘管不能保證）。

決定性因素是比較運算符應用於列的數據分佈（選擇性）。這與統計將決定索引是否使用等。

希望這是有道理的。

Answer 3

實際上。我只是試着用我的一些數據進行驗證。 BETWEEN等同於「> =」和「<」。例如：在'05/01/2010'和'05/30/2010'之間：您將只在5/1/2010 00:00:00至2010年5月29日23:59:59之間獲得數據。試着用「按時間順序排列」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毫秒

方法2：70毫秒

這樣看來，使用之間的性能得到提高。

Answer 5

當人們提供代碼來做自己的測試時，你需要做一個更大的子集/重複測試來解釋被加載到內存中的索引，等等......然後再跳到結論。下面是相同的代碼具有更大的桌子和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 

我就從這個說（仍然相當不科學）測試，沒有太大的區別無論哪種方式。

Answer 6

查詢引擎之間爲>=和<=（看看查詢計劃）將因此在實踐中，它們是相同的，並且在理論上>= <=是更快，因爲引擎不會有翻譯。祝你好運，但注意不同。

我之間使用，無論如何，我覺得它讀取容易

非常複雜的查詢/嵌套視圖與比較之間的許多可能更改受益到>= <=因爲這可能會潛在地阻止優化超時通過減少花費在重構查詢時間（只是一個理論，未經我測試&我從來沒有注意到它）