PythonQ 240-8XX Manual de usuario descargar pdf (Pagina 356)

100

101

Kapitel 6: MySQL-Optimierung 335

shell> myisamchk --analyze PFAD_ZU_MYSQL_DATENBANK/tt

shell> mysqladmin refresh

Jetzt ist der Join perfekt und EXPLAIN ergibt dieses Ergebnis:

table type possible_keys key key_len ref rows Extra

tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used

et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1

et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1

do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1

Beachten Sie, dass die rows-Spalte in der Ausgabe von EXPLAIN eine gehobene Form von

Vermutung des MySQL-Join-Optimierers ist. Um eine Anfrage zu optimieren, sollten Sie

¨uberpr ¨ufen, ob diese Zahlen der Wahrheit nahe kommen. Wenn nicht, erhalten Sie eventuell

bessere Performance, wenn Sie STRAIGHT_JOIN in Ihrem SELECT-Statement benutzen und

versuchen, die Tabellen in der FROM-Klausel in anderer Reihenfolge anzugeben.

6.2.2 Anfragen-Performance absch¨atzen

In den meisten F¨allen k¨onnen Sie die Performance sch¨atzen, indem Sie Suchvorg¨ange auf

Festplatte z¨ahlen. Bei kleinen Tabellen k¨onnen Sie die Zeile ¨ublicherweise mit 1 Festplatten-

Suchvorgang ﬁnden (weil der Index wahrscheinlich im Cache ist). Bei gr¨oßeren Tabellen

k¨onnen Sie sch¨atzen, dass Sie (bei der Benutzung von B++-Baum-Indexen) brauchen wer-

den: log(zeilen_zahl) / log(index_block_laenge / 3 * 2 / (index_laenge + daten_

zeiger_laenge)) + 1 Suchvorg¨ange, um die Zeile zu ﬁnden.

In MySQL ist ein Index-Block ¨ublicherweise 1024 Bytes lang und der Daten-Zeiger

¨ublicherweise 4 Bytes. Eine 500.000-Zeilen-Tabelle mit einer Indexl¨ange von 3 (medium

integer) ergibt: log(500.000)/log(1024/3*2/(3+4)) + 1 = 4 Suchvorg¨ange.

Da der obige Index etwa 500.000 * 7 * 3/2 = 5,2 MB ben¨otigen w¨urde (angenommen, dass

die Index-Puﬀer zu 2/3 gef¨ullt sind, was ein typischer Wert sit), haben Sie wahrscheinlich

viel vom Index im Arbeitsspeicher und werden wahrscheinlich nur 1 bis 2 Betriebssystem-

Aufrufe ben¨otigen, um Daten zu lesen, um die Zeile zu ﬁnden.

Bei Schreibvorg¨angen brauchen Sie jedoch 4 Suchanfragen (wie oben), um herauszuﬁnden,

wo der neue Index platziert wird, und normalerweise 2 Suchvorg¨ange, um den Index zu

aktualisieren und die Zeile zu schreiben.

Beachten Sie, dass oben Gesagtes nicht bedeutet, dass Ihre Applikation allm¨ahlich mit N log

N verf¨allt! Solange alles durch das Betriebssystem oder den SQL-Server gecachet wird, wer-

den die Dinge nur marginal langsamer, wenn die Tabellen gr¨oßer werden. Wenn die Daten zu

Groß werden, um gecachet zu werden, werden die Dinge anfangen, viel langsamer zu laufen,

bis Ihre Applikation schließlich komplett durch Suchvorg¨ange auf Festplatte ausgebremst

wird (die mit N log N zunehmen). Um das zu vermeiden, vergr¨oßern Sie den Index-Cache,

wenn die Daten wachsen. Siehe Abschnitt 6.5.2 [Server parameters], Seite 355.

6.2.3 Geschwindigkeit von SELECT-Anfragen

Wenn Sie ein langsames SELECT ... WHERE schneller machen wollen, ist im Allgemeinen

das erste, was zu pr¨ufen ist, ob Sie einen Index hinzuf¨ugen k¨onnen oder nicht. Siehe Ab-

schnitt 6.4.3 [MySQL-Indexe], Seite 349. Alle Verweise (Reference) zwischen verschiedenen

1 2 ... 351 352 353 354 355 356 357 358 359 360 361 ... 767 768

Comentarios a estos manuales

Sin comentarios

PythonQ 240-8XX Manual de usuario Pagina 356

Comentarios a estos manuales

Relacionado con productos y manuales para Sistema De Soldadura PythonQ 240-8XX