BETWEEN-Klausel gegen <= AND> =
Gibt es einen Leistungsunterschied zwischen der Verwendung einer BETWEEN-Klausel oder der Verwendung von <= AND> = Vergleichen?
diese beiden Abfragen:
SELECT *
FROM table
WHERE year BETWEEN '2005' AND '2010';
...und
SELECT *
FROM table
WHERE year >= '2005' AND year <= '2010';
In diesem Beispiel lautet die Jahresspalte VARCHAR2 (4) mit einem Index.
Es gibt keinen Leistungsunterschied zwischen den beiden Beispielabfragen, da BETWEEN einfach eine Abkürzung für das Ausdrücken von ist inklusive Bereichsvergleich. Wenn Oracle die BETWEEN-Bedingung analysiert, wird es automatisch in separate Vergleichsklauseln erweitert:
ex.
SELECT *
FROM table
WHERE column BETWEEN :lower_bound AND :upper_bound
... wird automatisch zu:
SELECT *
FROM table
WHERE :lower_bound <= column
AND :upper_bound >= column
Es gibt keinen Unterschied.
Beachten Sie, dass BETWEEN immer inklusiv ist und die Reihenfolge der Argumente berücksichtigt.
BETWEEN '2010' AND '2005' wird niemals TRUE sein.
Tatsächlich hängt es von Ihrer DBMS-Engine ab.
Einige Datenbankverwaltungssysteme berechnen Ihren Ausdruck zweimal (einmal für jeden Vergleich) und nur einmal, wenn Sie BETWEEN verwenden.
Wenn der Ausdruck ein nicht deterministisches Ergebnis haben kann, BETWEEN ein anderes Verhalten hat, vergleichen Sie in SQLite Folgendes:
WHERE RANDOM() BETWEEN x AND y -- one random value generated
WHERE RANDOM() >= x AND RANDOM() <= y -- two distinct random values generated
Dies kann sehr zeitaufwändig sein, wenn es sich bei Ihrem Ausdruck beispielsweise um eine Unterabfrage handelt.
Führen Sie im Zweifelsfall (für Oracle trotzdem) einen explain-Plan aus und Sie werden sehen, was der Optimierer tun möchte. Dies würde für die meisten Fragen gelten, ob es einen Leistungsunterschied zwischen ... gibt. Natürlich gibt es auch viele andere Tools, aber der Erklärungsplan ist ein guter Anfang.
Es ist sollte dasselbe.
Eine gute Datenbank-Engine generiert denselben Plan für diesen Ausdruck.
Es kann sich lohnen, den SQL-Standard in Betracht zu ziehen (obwohl möglicherweise nicht allen Implementierungen entspricht, selbst wenn sollte):
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".
Trotzdem gibt es keinen Unterschied im Verhalten, obwohl es für komplexe X Unterschiede in der Parsing-Zeit geben kann, wie von Benoit hier erwähnt.
Gefunden in http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Sie sollten Ihre Ausführungspläne besser überprüfen, da es einige seltsame Edge-Fälle geben kann, in denen BETWEEN einen anderen Ausführungsplan als die Standardkombination> = und <= haben kann.
Vorbehalt offensichtlich. Aber da sich Ausführungspläne im Laufe der Zeit ändern können und ich wirklich keinen Appetit habe, solche Dinge zu testen, verwende ich lieber überhaupt nicht ZWISCHEN.
Manchmal ist weniger Auswahl besser.
run1 "X> = Y UND X <= Z"
run2 "X ZWISCHEN Y UND Z"
Ich bekomme einen Plan hash value, wenn ich explain plan zweimal ausführen will.
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%