PythonQ 240-8XX Instrukcja Użytkownika Pobierz pdf (Strona 364)

100

101

Kapitel 6: MySQL-Optimierung 343

kann, oder wenn Sie die Tabelle sehr oft scannen m¨ussen, die meisten der Spalten

hierf¨ur aber nicht ben¨otigen. Siehe Kapitel 8 [Table types], Seite 482.

• Wenn Sie sehr oft etwas auf der Grundlage von Informationen aus sehr vielen Zeilen

berechnen m¨ussen (zum Beispiel Dinge z¨ahlen), ist es wahrscheinlich besser, eine neue

Tabelle einzuf¨uhren und den Z¨ahler in Echtzeit zu aktualisieren. Eine Aktualisierung

des Typs UPDATE tabelle set zaehler=zaehler+1 where index_spalte=konstante

ist sehr schnell!

Das ist sehr wichtig, wenn Sie Datenbanken wie MySQL benutzen, die nur Tabellensper-

ren haben (viele Leser / einzelne Schreiber). Bei den meisten sonstigen Datenbanken

ergibt das ebenfalls bessere Performance, weil der Zeilensperr-Manager weniger zu tun

haben wird.

• Wenn Sie Statistiken aus großen Log-Tabellen gewinnen wollen, benutzen Sie Zusam-

menfassungstabellen, statt die gesamte Tabelle zu scannen. Die Wartung der Zusam-

menfassungen sollte wesentlich leichter sein, als die Statistiken ’live’ zu generieren. Es

ist viel schneller, neue Zusammenfassungstabellen aus den Logs zu erzeugen, wenn sich

Dinge ¨andern (abh¨angig von Gesch¨aftsentscheidungen) als eine laufende Applikation

¨andern zu m¨ussen!

• Wenn m¨oglich sollte man Berichte als ’live’ oder ’statistisch’ klassiﬁzieren, wobei die

Daten, die f¨ur statistische Berichte ben¨otigt werden, nur auf der Grundlage von Zusam-

menfassungstabellen erzeugt werden, die aus den eigentlichen Daten generiert werden.

• Ziehen Sie Vorteile aus der Tatsache, dass Spalten Vorgabewerte haben. F¨ugen

Sie nur dann explizit Werte ein, wenn der einzuf¨ugende Wert vom Vorgabewert

abweicht. Das verringert das Parsen, das MySQL durchf¨uhren muss, und erh¨oht die

Einf¨ugegeschwindigkeit.

• In einigen F¨allen ist es bequem, Daten zu komprimieren und in einem Blob zu speichern.

In diesem Fall m¨ussen Sie in Ihrer Applikation etwas zus¨atzlichen Code unterbringen,

um die Dinge im Blob zu packen bzw. zu entpacken. Das kann aber in manchen Phasen

etliches an Zugriﬀen einsparen. Das ist praktisch, wenn Sie Daten haben, die mit einer

statischen Tabellenstruktur nicht konform sind.

• Normalerweise sollten Sie versuchen, alle Daten nicht redundant zu halten (was sich

in der Datenbanktheorie dritte Normalform nennt). Scheuen Sie sich aber nicht da-

vor, Dinge zu duplizieren oder Zusammenfassungstabellen zu erzeugen, wenn Sie dies

brauchen, um mehr Geschwindigkeit zu erzielen.

• Gespeicherte Prozeduren (Stored Procedures) oder UDF (user deﬁned functions, be-

nutzerdeﬁnierte Funktionen) sind eine gute M¨oglichkeit, mehr Performance zu erzielen.

Sie sollten jedoch immer eine andere (langsamere) M¨oglichkeit parat haben, wenn Sie

eine Datenbank benutzen, die gespeicherte Prozeduren nicht unterst¨utzt.

• Man erreicht immer etwas, wenn man Anfragen / Antworten in der Applikation ca-

chet und versucht, viele Einf¨uge- oder Aktualisierungsvorg¨ange zugleich durchzuf¨uhren.

Wenn Ihre Datenbank Tabellensperren unterst¨utzt (wie MySQL und Oracle), sollte

das dazu f¨uhren, dass der Index-Cache nur einmal auf Platte zur¨uck geschrieben wird,

nachdem alles Einf¨ugen / Aktualisieren ausgef¨uhrt ist.

• Benutzen Sie INSERT /*! DELAYED */, wenn Sie nicht wissen brauchen, wann Ihre

Daten geschrieben werden. Das erh¨oht die Geschwindigkeit, weil viele Datens¨atze mit

einem einzige Festplattenschreibzugriﬀ geschrieben werden k¨onnen.

1 2 ... 359 360 361 362 363 364 365 366 367 368 369 ... 767 768

Komentarze do niniejszej Instrukcji

Brak uwag

PythonQ 240-8XX Instrukcja Użytkownika Strona 364

Komentarze do niniejszej Instrukcji

Powiązane produkty i podręczniki dla System spawalniczy PythonQ 240-8XX