langsame Datenbankabfrage

[Wapmaster]

Hallo zusammen,

ich habe hier eine Datenbankabfrage, welche auch funktioniert, jedoch seeeeehr sehr langsam ist.

$max wird gegeben, ist klar,

$recode ebenfalls gegeben, enthält eine Kategorien-Abkürzung, die übereinstimmen soll

-> die $max letzten Kommentare aller Produkte der Kategorie-Abkürzung $recode sollen gelistet werden

SELECT b.*, h.PRODUKTID, h.SI, c.SI, c.ZI

FROM kommentare b, produkte h, kategorien c

WHERE

b.PRODUKTID= h.PRODUKTID

AND h.SI = c.SI

AND c.ZI = '$recode'

ORDER BY b.LOGDATE DESC

LIMIT $max

noch eine Info: die Abfrage braucht derzeit mind. 20 Sekunden, maximal 60 Sekunden. Tabelle kommentare hat 1000 einträge, derzeit, produkte sind 40.000 und kategorien 13.500. Letztere beiden bleiben konstant.

[robotto7831a]

Hallo,

hast Du mal einen Index angelegt?

Frank

[Wapmaster]

hui, das geht aber zackig :uli

hat jemand lust das in kurzform zu erklären, warum das nun so schnell ist?

hab nen index auf alle spalten die benutzt werden ausser in der kommentar tabelle gesetzt. was macht der denn da?

[kingofbrain]

Wenn die Datenbank einen Index auf eine oder mehrere Tabellen setzt, dann muss sie bei einem select nicht mehr alle Datensätze durchsuchen, sondern sie kann anhand des Indizes schon einen Haufen Datensätze ausschliessen.

Wie es technisch funktioniert ist von Datenbank zu Datenbank verschieden. Ein oft gewählter Ansatz ist eine Binärbaumstruktur. Dabei wird z.B. bei einer Dezimalzahlspalte die Gesamtanzahl der Datensätze in zwei Teile geteilt. Der eine Teil kleiner einer bestimmten Zahl, der andere Teil grösser (die gewählte Zahl liegt also genau in der Mitte). Danach wird der erste Teil nach dem selben Verfahren geteilt und so weiter. Wenn jetzt eine Abfrage kommt, die die Zahl einschränkt, dann hangelt sich die DB am Baum entlang.

Beispiel:

Datensätze: 1, 1, 4, 3, 4, 7, 5, 5, 9, 8, 6, 2

wird in den folgenden Binärbaum geteilt:

1, 1, 2, 3, 4, 4

5, 5, 6, 7, 8, 9

1, 1, 2,

3, 4, 4,

5, 5, 6,

7, 8, 9,

usw.

Bei einer Suche nach der Zahl 6 muss jetzt nicht mehr jeder Datensatz verglichen werden sondern nur noch folgender Ablauf:

Ist die Zahl kleiner als 5? Nein, also zweiter Ast -> ist die Zahl kleiner als 7? Nein, also 3. Ast -> Und da müsste in unserem Beispiel dann dreimal verglichen werden, bei einem weiter gesplitteten Baum evtl. weniger.

Peter

[Wapmaster]

okay, super

danke für die hilfe und danke für die wunderbare erklärung hehe

[mme]

Grundsätzlich währe mal wieder interessant welche Datenbank...

Die Ausführungen von Kingogbrain könnten darauf schließen, das es durch einen INdex immer schneller wird. Dies muss nicht umbedingt sein. Es gibt viele Situationen wo es bedeutend schneller geht (je nach dbms) auf bestimmte spalten gerade keinen index zu haben...

Dies nur als kleine Anmerkung...

[kingofbrain]

Servus,

das liegt aber dann daran, dass die Indexerstellung und -verwaltung auch Zeit und Speicher kostet. Eine Indizierung sollte auf die eigrenzenden Attribute gesetzt werden und nur auf diese.

Peter

[Jasper]

das liegt aber dann daran, dass die Indexerstellung und -verwaltung auch Zeit und Speicher kostet. Eine Indizierung sollte auf die eigrenzenden Attribute gesetzt werden und nur auf diese.

das ist zwar richtig, aber nicht der hauptgrund. entscheidend ist der quotient resultset/gesamtmenge, d.h. übersteigt die menge an zurückgelieferten zeilen einen bestimmten wert, wird die verwendung eines index teurer als ein FTS. der schwellwert hängt von daten/datenverteilung ab, liegt aber so um die 10-20%.

deshalb sind datenbanksysteme mit festen optimizern bei grossen datenmengen oftmals im nachteil.

-j

[Jaraz]

FTS

????????????

[Jasper]

????????????

sorry, hätte ich ausschreiben sollen:

FTS == Full Table Scan

-j

[kingofbrain]

Ah ja, das wusste ich noch nicht. Danke für die Erläuterung.

Peter

[Wapmaster]

ja wirklich sehr informativ diese diskussion

ich dachte ich wüsste schon viel aber dem scheint nicht so zu sein *g

auf jeden fall weiss ich eins: hier wird einem geholfen hehe