Performance Steigerung bei WHERE-Sortierung?

Morgen NG,

Macht es einen Performanceunterschied, wenn man die WHERE Bedingungen so
anordnet, dass sie bereits am Anfang möglichst viel ausschließen?

z.B.:
WHERE
authorid = '$aAuthorID' AND
activated = 1

anstatt von:
WHERE
activated = 1 AND
authorid = '$aAuthorID' AND


mfg,
Ricardo Wickel

--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Performance Steigerung bei WHERE-Sortierung?

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Performance Steigerung bei WHERE-Sortierung?

Ricardo Wickel schrieb:
> Morgen NG,
>=20
> Macht es einen Performanceunterschied, wenn man die WHERE Bedingungen s=
o=20
> anordnet, dass sie bereits am Anfang möglichst viel ausschließ=
en?
>=20
> z.B.:
> WHERE
> authorid =3D '$aAuthorID' AND
> activated =3D 1
>=20
> anstatt von:
> WHERE
> activated =3D 1 AND
> authorid =3D '$aAuthorID' AND

Nein.

im Übrigen ist die Antwort vom Kretschmer eher unerheblich, was die =

Nutzung von Mysql betrifft.

Re: Performance Steigerung bei WHERE-Sortierung?

Ricardo Wickel wrote:
>
> Macht es einen Performanceunterschied, wenn man die WHERE Bedingungen so
> anordnet, dass sie bereits am Anfang möglichst viel ausschließen?
>
> z.B.:
> WHERE
> authorid = '$aAuthorID' AND
> activated = 1
>
> anstatt von:
> WHERE
> activated = 1 AND
> authorid = '$aAuthorID' AND

Nein, bei so einfachen Sachen nicht.

Bei komplexeren Bedingungen schon. Z.B. statt
.... WHERE SQRT((xpos-3)*(xpos-3) + (ypos-4)*(ypos-4)) <= 2
(Koordinaten (xpos, ypos) in einem Kreis mit Radius 2 um (3,4))

besser:
.... WHERE (xpos BETWEEN 1 and 5)
AND (ypos BETWEEN 2 AND 6)
AND ((xpos-3)*(xpos-3) + (ypos-4)*(ypos-4) <= 4)

-> der längliche Ausdruck muß nur für Punkte berechnet werden, die
innerhalb des umschließenden Quadrats liegen
-> ein Index auf (xpos, ypos) kann benutzt werden
-> die Wurzel kann man einsparen


XL

Re: Performance Steigerung bei WHERE-Sortierung?

Axel Schwenke schrieb:
> Ricardo Wickel wrote:
>
>>Macht es einen Performanceunterschied, wenn man die WHERE Bedingungen so
>>anordnet, dass sie bereits am Anfang möglichst viel ausschließen?
>>
>>z.B.:
>>WHERE
>> authorid = '$aAuthorID' AND
>> activated = 1
>>
>>anstatt von:
>>WHERE
>> activated = 1 AND
>> authorid = '$aAuthorID' AND
>
>
> Nein, bei so einfachen Sachen nicht.
>
> Bei komplexeren Bedingungen schon. Z.B. statt
> ... WHERE SQRT((xpos-3)*(xpos-3) + (ypos-4)*(ypos-4)) <= 2
> (Koordinaten (xpos, ypos) in einem Kreis mit Radius 2 um (3,4))
>
> besser:
> ... WHERE (xpos BETWEEN 1 and 5)
> AND (ypos BETWEEN 2 AND 6)
> AND ((xpos-3)*(xpos-3) + (ypos-4)*(ypos-4) <= 4)
>
> -> der längliche Ausdruck muß nur für Punkte berechnet werden, die
> innerhalb des umschließenden Quadrats liegen
> -> ein Index auf (xpos, ypos) kann benutzt werden
> -> die Wurzel kann man einsparen

Du hast die Frage wohl falsch verstanden.

Ricardo wollte wissen, ob die REIHENFOLGE in der die Where-Bedingungen
notiert werden, relvant ist.

Und die Antwort darauf lautet: NEIN (zumindest bim aktuellen Optimizer).

Du hast auf eine andere Frage geantwortet.
((xpos-3)*(xpos-3) + (ypos-4)*(ypos-4) <= 4)
und
SQRT((xpos-3)*(xpos-3) + (ypos-4)*(ypos-4)) <= 2

ist nämlich aus der Sicht des Auschlussmenge exakt gleich.

So far,
Michael

Re: Performance Steigerung bei WHERE-Sortierung?

Axel Schwenke wrote:
> besser:
> ... WHERE (xpos BETWEEN 1 and 5)
> AND (ypos BETWEEN 2 AND 6)
> AND ((xpos-3)*(xpos-3) + (ypos-4)*(ypos-4) <= 4)
>
> -> der längliche Ausdruck muß nur für Punkte berechnet werden, die
> innerhalb des umschließenden Quadrats liegen
> -> ein Index auf (xpos, ypos) kann benutzt werden

Ein WHERE x BETWEEN ... AND y BETWEEN ... nutzt nur einen Index auf x, wenn
ein BTREE bereitgestellt wird. Um x und y zu nutzen muss man einen RTREE
verwenden (und dazu (x,y) als GIS POINT TYPE bereit stellen).

Kris

Re: Performance Steigerung bei WHERE-Sortierung?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Performance Steigerung bei WHERE-Sortierung?

Kristian Köhntopp schrieb:
> Ein WHERE x BETWEEN ... AND y BETWEEN ... nutzt nur einen Index auf x, =
wenn
> ein BTREE bereitgestellt wird. Um x und y zu nutzen muss man einen RTRE=
E
> verwenden (und dazu (x,y) als GIS POINT TYPE bereit stellen).

kannst du das irgenwie näher erläutern? Mir ist soetwas äh=
nliches=20
bereits bei OR Abfrage aufgefallen - aber wie man einen r-tree=20
bereitstellt?

--=20
Werner

Re: Performance Steigerung bei WHERE-Sortierung?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Performance Steigerung bei WHERE-Sortierung?

werner bauer wrote:
> Kristian Köhntopp schrieb:
>> Ein WHERE x BETWEEN ... AND y BETWEEN ... nutzt nur einen Index auf x, wenn
>> ein BTREE bereitgestellt wird. Um x und y zu nutzen muss man einen RTREE
>> verwenden (und dazu (x,y) als GIS POINT TYPE bereit stellen).
>
> kannst du das irgenwie näher erläutern? Mir ist soetwas ähnliches
> bereits bei OR Abfrage aufgefallen - aber wie man einen r-tree
> bereitstellt?

Ein R-Tree ->[1] ist ein mehrdimensionaler Index. MySQL verwendet
R-Trees für die Indizierung von Geodaten ->[2].

Das mit OR ist eine andere Geschichte. Vor 5.0 konnte der Query-Planner
von MySQL pro Tabelle nur einen Index benutzen. Z.B. WHERE x=1 OR y=42
benutzt entweder einen Index auf x oder einen auf y. Mit 5.x wurde
"index merging" ->[3] eingeführt, das diesen Teil optimiert.

[1] http://de.wikipedia.org/wiki/Rtree
[2] http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.ht ml
[3] http://dev.mysql.com/doc/refman/5.0/en/index-merge-optimizat ion.html


XL