Сравните разницу в производительности T-SQL между и оператором <<'>>? - PullRequest
14 голосов
/ 28 мая 2009

Я пробовал искать в поисковых системах, MSDN и т. Д. но ничего не могу Извините, если об этом уже спрашивали. Есть ли разница в производительности между использованием ключевого слова T-SQL «Между» или операторами сравнения?

Ответы [ 6 ]

24 голосов
/ 28 мая 2009

Вы можете проверить это достаточно легко, проверив планы запросов в обеих ситуациях. Нет разницы, о которой я знаю. Хотя есть логическая разница между МЕЖДУ и "<" и ">" ... МЕЖДУ включительно. Это эквивалентно "<=" и "=>".

5 голосов
/ 08 октября 2012

Механизм запросов преобразуется между >= и <= (взгляните на план запроса), поэтому на практике они идентичны, а в теории >= <= быстрее, потому что механизм не должен переводиться. Удачи, заметив разницу, хотя.

В любом случае я использую между ними, мне легче читать

Очень сложные запросы / вложенные представления с множеством сравнений могут выиграть от перехода на >= <=, поскольку это может предотвратить тайм-ауты оптимизации, сократив время, затрачиваемое на рефакторинг запроса (просто теория, не проверенная мной, и я никогда заметил это)

1 голос
/ 27 сентября 2012

Любите, когда люди дают код для собственного тестирования, вам нужно выполнить более крупное подмножество / повторный тест, чтобы учесть индексы, загружаемые в память и т. Д., Прежде чем делать выводы. Вот тот же код с таблицей большего размера и 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

Я бы сказал, из этого (все еще довольно ненаучного) теста, в любом случае нет большой разницы.

0 голосов
/ 11 мая 2012

Меня также интересовало, есть ли разница в производительности при использовании (> = и <=) по сравнению с использованием ключевого слова Между. (Я пришел из точечного фона и люблю операторы стиля> =).
Вот скрипт, который я использовал:

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 голосов
/ 10 июля 2010

на самом деле. Я просто пытаюсь проверить некоторые из моих данных. МЕЖДУ эквивалентно "> =" и "<". Например: в период с «05/01/2010» по «05/30/2010»: вы будете получать данные только с 5/1/2010 с 00:00:00 по 29/05/2010 в 23:59:59. Попробуйте запросить в таблице «Order by [TimeField] desc», и вы увидите результат. </p>

0 голосов
/ 28 мая 2009

Два оператора, которые здесь сравниваются друг с другом, принципиально различаются, и поэтому сгенерированные планы выполнения также могут отличаться (хотя и не гарантировано).

Определяющим фактором является распределение данных (селективность) столбца, к которому применяются операторы сравнения. Это вместе со статистикой будет определять, используется индекс или нет и т. Д.

Надеюсь, это имеет смысл.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...