MySQL-Server schonen?

**pekka** · 29.12.2008, 10:57

Hast Du denn Indexe gesetzt für jede Spalte der von den Joins betroffenen Tabellen, wie mySQL es empfiehlt? Das reduziert die Last für die Datenbank nämlich erheblich.

Wenn Du viele Seiten mit sich selten ändernden Inhalten auslieferst, kann eventuell eine Template-Engine wie Smarty helfen, die Datenbanklast zu schonen.

Ansonsten hilft nur das Aufspüren der Laststellen mittels ordentlichem Profiling. Da müssen wir alle durch

**combie** · 29.12.2008, 11:38

EXPLAIN SELECT ....
Kann dabei ungemein hilfreich sein.

**Blackgreetz** · 29.12.2008, 17:22

Original geschrieben von pekka
Hast Du denn Indexe gesetzt für jede Spalte der von den Joins betroffenen Tabellen, wie mySQL es empfiehlt? Das reduziert die Last für die Datenbank nämlich erheblich.

Bis jetzt wohl eher nicht:

PHP-Code:


"SELECT * FROM images LEFT JOIN favcards ON ( id = BildID AND UserID =".$userid." ) WHERE category = ".$cat;

Wäre es viel schneller, wenn ich statt images.* auch noch images.[Spalten] schreiben würde?

@combie: Guck ich mir gleich mal an

mfg

**TobiaZ** · 29.12.2008, 17:31

Wie kannst du an dieser Query erkennen, ob die Tabellen nen entsprechenden Index haben oder nicht?

Das aufzählen den Spalten ist zwar generell zu empfehlen, dürfte aber im Normalfall nur wenig in Richtung Performance bringen.

**combie** · 29.12.2008, 18:09

Das aufzählen den Spalten ist zwar generell zu empfehlen, dürfte aber im Normalfall nur wenig in Richtung Performance bringen.

Sehe ich auch so!
Zumindest wenn dort keine/wenige BLOB und TEXT bei sind.

**Blackgreetz** · 29.12.2008, 18:26

Okay.

Zum Thema Index: Ich hab den Begriff wohl falsch interpretiert.

Ihr wolltet auf Primary Key usw. raus?

Wenn ich einfach mal bei deim JOIN da bleibe:

Tabelle images:
ID = Primary Key ... somit ein Index..

Die Tabelle favcards hat keinen Index. Zumindest keinen so explizit definierten Index.

Sie setzt sich nur aus der BildID & UserID zusammen.
BildID = ID der Tabelle images
UserID = ID der Tabelle user (dort auch Primary key)

Nun kann ich weder BildID, noch UserID die Eigenschaft Primary Key oder unique geben. Bleibt also theoretisch nur INDEX.

Dann müsste ich aber theoretisch beiden Feldern den INDEX geben, oder nicht? - wäre das nicht widersprüchlich bzw. uneffektiv?

mfg

**combie** · 29.12.2008, 18:30

Du könntest auch einen kombinierten Index auf BEIDE Spalten legen.
Das ist ab und an besser als immer nur einzelne Spalten mit einem Index zu versehen.

Aber wie gesagt:
Experimentiere mit EXPLAIN ...
Dessen Ausgabe ist das Maß aller Dinge!

**Blackgreetz** · 11.12.2009, 20:41

Hi,

lange ists her, aber nun ist ja bald wieder Weihnachten, .. da stellt sich wieder dieses Problem.

Ich hab nun mit Explain da experimentiert. Für den oben angegebenen Join stand ALL, ALL da. Also -> super mies.

Darauf hin habe ich in der Tabelle favcards einen kombinierten PK auf beide Spalten gelegt, sodass es von ALL auf eq_ref geändert wurde und bei rows nur noch 1 steht, statt der Anzahl der Einträge in der Tabelle.

Kann ich somit davon ausgehen, dass solch ein kombi- PK bei der Zusatztabelle der n:n-Beziehung Standard ist? (also man es immer so macht?)

Ich hab dann allerdings noch ein Problem.

Tabelle: Kategorie
ID Primary Key,
name varchar(50)

Tabelle: Images
ID Primary Key,
category INT

Nun ist ja zwischen Images und Kat. noch eine 1:n - Beziehung (category - Kat.ID). Somit ist category ja der Fremdschlüssel im Ref. auf den PK bei Kategorie. In MySQL funktionieren aber Foreign Keys - Angaben ja nur unter InnoDB, richtig?
Meine DB nutzt zwar dieses Format, aber soll man sich dann auch darauf festlegen? Wenn ja, was ist, wenn man einen Serverwechsel hat und dort nutzt man statt InnoDB ->MyISAM. Dann müsste man ja theoreitsch die Tabellen wieder ändern, wenn man "FK-Angaben" nutzt.

Frage: Soll man nun angeben, dass es sich um einen FK handelt und sich somit festlegen auf InnoDB, oder nicht?
PHPMyAdmin hat mir vorgeschlagen, als ich einen Index in 'images' hinzufügen wollte, PK, Unique, FullText und Index.
PK geht ja nicht, ist ja bereits ID. Unique wäre unsinnig, weil ja mehrere Bilder in ein und die selbe Kategorie fallen können und FullText auf den INT-Schlüssel..., naja. Bleibt also nur noch ein ein Index auf "category" legen zu können.

Bleibt am ende: Index oder FK?

Wenn ich einen FK auf category lege, bleiben nur die effected rows statt aller Einträge übrig. und ALL -> ref.

Hoffe ich hab mich halbwegs verständlich ausgedrückt und mich nicht zu doof angestellt.

mfg
Edit: Vlt wäre das Thema jetzt in nem anderen Forum als Brainstorming besser aufgehoben.

MySQL-Server schonen?