Sehr große MySql-Tabelle: Tipps, Tricks und Dinge auf die man achten muss...!?

B

Bailor

Ich arbeite seit einiger Zeit mit einer wirklich großen Tabelle (27 MioEinträge; 2,4 GB Daten), und hab da nun aber entsprechend nur meine ersten Erfahrungen gesammelt, und grüble des Öfteren über die "optimale Lösung" für verschiedene Probleme...

Gibts hier im Forum Leute, der mit rießigen Datenmengen Erfahrung haben und mir evtl. noch ein paar Tipps geben können, auf welche Dinge ich achten sollte...? Zum Beispiel welche Befehle in Queries besonders langsam sind, ob Indexe sich auch noch lohnen, wenn sie 5 min. zum Aufbauen brauchen (und somit entsprechend groß sind), ab wann man besser über ein anderes Datenbanksystem nachdenken sollte, ... etc.

Vielleicht weis jemand auch ein paar gute Links zu Seiten, Beiträgen oder Artikeln, die in der Hinsicht weiterhelfen...?
Würd mich freuen, wenn einige Datenbankexperten hier ihre Erfahrungen mit Monstertabellen weitergeben würden... :)
 
Also ohne detailliertere Angaben kann ich dir nicht viel weiter helfen.

Ich habe unter MySql einmal eine 6GB große Tabelle gehabt (auch etwa 25 Mio Einträge).

Durch geeignete Indexe blieb der Zugriff dennoch sehr schnell.

Wichtig: Indexe lohnen sich gerade dann, wenn Tabellen groß werden!
Hier kann man allerdings eine Menge gut oder besser machen.

Ich empfehle Dir die MySql-Homepage. Dort kannst Du auch etwas über Optimierungen lesen.

Bei gezielteren Fragen könnten evtl. auch hilfreichere Antworten rauskommen.;)

vop
 
Indices empfehlen sich gerade dann, wenn eine Tabelle viel gelesen wird und seltener aktualisiert. Bei der Auswahl, welche Spalten man indiziert, sollte man aber mit Bedacht vorgehen. Einfach auf jede Spalte einen Index zu legen ist kontraproduktiv, aus viele Gründe, die man sich eigentlich denken kann.
Indiziert werden sollten folgende Spalten: diejenige(n), über die häufig selektiert wird (selektiert im Sinne der rel. Algebra, also das, was in der WHERE-Klausel steht, nicht nach SELECT!) sowie die, über die mit anderen Tabellen gejoined wird. Der Grund ist dabei, dass der interne Optimierer bei der Auswahl des Join-Algorithmus auf die Indices zurückgreifen kann und einen Index-Join oder Double-Index-Join wählen kann, welche meist performanter sind als andere Algorithmen (Nested-Loop, Sort-Join, auch Hash-Join). Normalerweise ist dies aber gegeben, wenn man brav seine Schlüssel und Fremdschlüssel anlegt.
 
Danke für eure Antworten (und sry, dass ich erst jetzt antworte).

Den Bereich Optimization in der Mysql-Dokumentation ich schon schätzen gelernt, er ist sehr umfangreich - ich frage mich nur, ob man eventuell bestimmte Dinge benennen kann, die besonders wichtig bzw. besonders effektiv beim optimieren sind...

Christoph, du hast geschrieben, dass sich Indices vor allem bei großen kaum veränderten tabellen lohnt... die Tabelle, mit der ich arbeite, wird allerdings täglich aktualisiert und mit neuen Werten gefüllt. (ja, immense Datenmengen, man braucht ne super-Leitung...). Ein Problem?

Die kritische Abfrage beinhaltet einen LEFT JOIN, dafür ist ein index über die entsprechenden 2 spalten gesetzt... (ein index, der über nen gb groß ist und entsprechend lang zum aufbauen braucht).

Nach den beiden Posts könnt man meinen, dass Indices wohl am wichtigsten für die Performance sind... richtig? :)
Naja: und was kommt dann?
 
Bezüglich der Aktualisierung: häufige Updates sind insofern ein "Problem" als dass bei UPDATE oder INSERT auch der Index aktualisiert werden muss, d.h. Änderungen werden langsamer als vorher. Wo da der Break-Even-Point ist, kann man aber nicht mathematisch berechnen. Da helfen nur Gefühl, Erfahrung und Ausprobieren (ein Index lässt sich ja auch wieder verwerfen, und bei Schlüsseln kommst du um einen Index ohnehin nicht rum).
Ansonsten fällt mir jetzt spontan noch folgendes ein: ich weiß jetzt nicht auswendig, wie MySQL Selektionen optimiert, d.h. ob die Bedingung, die wahrscheinlich am selektivsten ist (sprich: die aus der Relation die meisten Tupel aussortiert), anhand eines Modells oder Heuristiken ermittelt werden kann. Von Hand kann man evtl. so nachhelfen: die selektivste Bedingung gleich hinter WHERE oder ganz am Schluss, da bin ich mir nicht sicher, in welcher Reihenfolge ausgewertet wird und ob der interne Optimierer nicht stark umbaut. Dazu müsste aber was im MySQL-Manual stehen, wenn ich mich nicht ganz täusche...
Weiterhin helfen, wenn sich Abfragen gleicher Syntax oft wiederholen, Prepared Statements. Mit JDBC wie gehabt, auch die C-API, welche seit Version 4.1 neue Funktionen beinhaltet, die mit "mysqli" beginnen. Und damit gibt es sie auch in Skriptsprachen wie PHP, deren Interpreter für einen Aufruf dieser C-Funktionen sorgen.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück