Между предложением и <= AND> =

Question

Есть ли разница в производительности между использованием предложения BETWEEN или использованием <= AND> = сравнений?

, т.е. этими двумя запросами:

SELECT *  
  FROM table  
 WHERE year BETWEEN '2005' AND '2010';  

... и

SELECT *  
  FROM table  
 WHERE year >= '2005' AND year <= '2010';

В этом примере столбцом года является VARCHAR2 (4) с индексом.

Answer 1

Разницы нет.

Обратите внимание, что BETWEEN всегда включительно и чувствителен к порядку аргументов.

BETWEEN '2010' AND '2005' никогда не будет TRUE.

Answer 2

Нет разницы в производительности между двумя примерами запросов, потому что BETWEEN - это просто сокращенный способ выражения включающего сравнения диапазона. Когда Oracle анализирует условие BETWEEN, оно автоматически расширяется в отдельные пункты сравнения:

ех.

SELECT *  
  FROM table
 WHERE column BETWEEN :lower_bound AND :upper_bound  

... автоматически станет:

SELECT *  
  FROM table
 WHERE :lower_bound <= column
   AND :upper_bound >= column

Answer 3

На самом деле это зависит от вашего движка СУБД.

Некоторые системы управления базами данных будут вычислять дважды ваше выражение (один раз для каждого сравнения) и только один раз при использовании BETWEEN.

На самом деле, если выражение может иметь недетерминированный результат BETWEEN будет иметь другое поведение, сравните следующее в SQLite:

WHERE RANDOM() BETWEEN x AND y -- one random value generated

WHERE RANDOM() >= x AND RANDOM() <= y -- two distinct random values generated

Это может занять очень много времени, если ваше выражение (например) является подзапросом.

Answer 4

Если вы сомневаетесь (для Oracle в любом случае), запустите объясните план , и вы увидите, что оптимизатор хочет сделать.Это относится к большинству вопросов о «есть ли разница в производительности между ...».Конечно, есть и много других инструментов, но план объяснения - это хорошее начало.

Answer 5

Возможно, стоит рассмотреть стандарт SQL для этого (хотя может не соответствовать всем реализациям, даже если должно ):

Format

<between predicate> ::=
  <row value constructor> [ NOT ] BETWEEN
    <row value constructor> AND <row value constructor>

Syntax Rules

[...]

6) "X BETWEEN Y AND Z" is equivalent to "X>=Y AND X<=Z".

Сказав это, нет различий в поведении, хотя для сложных X, может быть разница во времени синтаксического анализа, как упоминалось Бенуа здесь

найдено в http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

Answer 6

Это должно быть таким же.

Хороший движок базы данных сгенерирует тот же план для этого выражения.

Answer 7

Вам лучше проверить свои планы выполнения, потому что могут быть некоторые странные крайние случаи, когда BETWEEN может иметь план выполнения, отличный от стандартной комбинации> = и <=. </p>

https://blog.pythian.com/oracle-can-between-and-greater-than-or-equal-to-and-less-than-or-equal-to-differ/

Будьте бдительны. Но поскольку планы выполнения могут со временем меняться, и у меня действительно нет желания испытывать подобные вещи, я скорее вообще не использую МЕЖДУ.

Иногда меньше выбора, тем лучше.

Answer 8

run1 "X> = Y AND X <= Z" </p>

run2 "X МЕЖДУ Y И Z"

Я получаю один Plan hash value, когда запускаю план объяснения дважды. Но ТомС runStats_pkg получает другой результат:

Run1 ran in 1 cpu hsecs
Run2 ran in 1 cpu hsecs
run 1 ran in 100% of the time

Name                      Run1    Run2        Diff
STAT...recursive calls          12      13       1
STAT...CPU used by this sessio       2       3       1
STAT...physical read total IO        0       1       1
STAT...consistent gets          18      19       1
...
...
LATCH.row cache objects         44,375   1,121     -43,254
LATCH.cache buffers chains      68,814   1,397     -67,417
STAT...logical read bytes from     655,360     573,440     -81,920
STAT...session uga memory max      123,512       0    -123,512
STAT...session pga memory      262,144  65,536    -196,608
STAT...session pga memory max      262,144  65,536    -196,608
STAT...session uga memory     -327,440  65,488     392,928

Run1 latches total versus runs -- difference and pct
Run1        Run2    Diff       Pct
203,927      28,673    -175,254    711.22%