2009-05-28 49 views

回答

23

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

+0

好點。我沒有注意到的微妙之處。 – 2009-05-28 14:59:43

1

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

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

希望這是有道理的。

+0

不確定爲什麼這被拒絕。約翰說了些什麼是錯的?有人不舒服?有人有主意嗎? – wcm 2009-05-28 15:40:41

+0

我從來沒有改變原來的問題。我也沒有投票。 – 2009-05-28 16:07:35

+0

這個答案對我來說很有意義......所以這次投票很奇怪 – Michael 2010-06-20 12:04:37

0

實際上。我只是試着用我的一些數據進行驗證。 BETWEEN等同於「> =」和「<」。例如:在'05/01/2010'和'05/30/2010'之間:您將只在5/1/2010 00:00:00至2010年5月29日23:59:59之間獲得數據。試着用「按時間順序排列」desc查詢你的表格,你會看到結果。

0

與使用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毫秒

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

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

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

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

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