nicht angemeldet
mysql hängt manchmal
TS
Rolf bHallo, wenn ich in einer Tabelle ein Insert machen möchte, kommt es manchmal vor, dass der Insert verhältnissmäßig lange braucht, wenn ich schon lange bei der Tabelle keinen Insert gemacht hatte. WEnn ich danach gleich nochmals einen Insert mache, geht es super schnell. An was könnte dies liegen.
Gibt es eine Empfehlung, wie ich die MySQL noch etwas "tunen" kann.
-
Tach!
Hallo, wenn ich in einer Tabelle ein Insert machen möchte, kommt es manchmal vor, dass der Insert verhältnissmäßig lange braucht, wenn ich schon lange bei der Tabelle keinen Insert gemacht hatte. WEnn ich danach gleich nochmals einen Insert mache, geht es super schnell. An was könnte dies liegen.
Als eine unmaßgebliche Vermutung fällt mir eine Index-Behandlung ein. Da hab ich aber keine Erfahrung, ob das solche Auswirkungen hat. Ist das denn überhaupt eine gesicherte Erkenntnis, dass MySQL die Ursache ist? Ist es ausgeschlossen, dass andere Prozesse in einem solchen Fall eine Initialisierungsphase brauchen?
Gibt es eine Empfehlung, wie ich die MySQL noch etwas "tunen" kann.
Ja, Ursachen genau ermitteln, dann erst handlen. Ansonsten kann es im ungünstigen Fall passieren, dass du keine Änderung im Verhalten siehst, den geänderten Parameter drin lässt und der im Falle eines Falles ungünstige Auswirkungen hat. Konkretes kann ich leider nicht beitragen.
dedlfix.
-
Hallo und guten Morgen,
Hallo, wenn ich in einer Tabelle ein Insert machen möchte, kommt es manchmal vor, dass der Insert verhältnissmäßig lange braucht, wenn ich schon lange bei der Tabelle keinen Insert gemacht hatte. WEnn ich danach gleich nochmals einen Insert mache, geht es super schnell.
Dazu müsstest Du schon ein wenig mehr erzählen.
- welche MySQL-Version?
- auf welchen OS?
- welcher Tabellentyp?
- betroffenes Datenmodell
- nur eine Tabelle?
- Wieviele Indexe? Sofort erneuert?
- Stored Routines und Trigger?
- Logging?
Und dann kann man durchaus in den Einstellungen von MySQL die Speicherverwendung optimieren.
Aber Dedlfix Rat, erst genau nach den Ursachen zu forschen, möchte ich da auch wiederholen.
Grüße
TS-
- welche MySQL-Version?
5.5.53-0ubuntu0.14.04.1
- auf welchen OS?
5.5.53-0ubuntu0.14.04.1
- welcher Tabellentyp?
InnoDB
- betroffenes Datenmodell
ALLE
** nur eine Tabelle?
In der DB sind aktuell 102 Tabellen
** Wieviele Indexe? Sofort erneuert?
Die Tabelle hat 4 Indexes. Werden immer sofort erneuert, oder wie kann man das einstellen.
** Stored Routines und Trigger?
Veränderungen werden bei UPDATE und INSERT getriggert
** Logging?
NEIN
-
Hallo und guten Tag,
- betroffenes Datenmodell ALLE
Na, da fällt mir nur die Universalantwort ein:
Es ist Tabelle Nr. 42
Da stimmt der Fluxwert vom Index im dritten Join nicht.Bitte etwas genauer!
Grüße
TS
-
Hallo, wenn ich in einer Tabelle ein Insert machen möchte, kommt es manchmal vor, dass der Insert verhältnissmäßig lange braucht, wenn ich schon lange bei der Tabelle keinen Insert gemacht hatte. WEnn ich danach gleich nochmals einen Insert mache, geht es super schnell. An was könnte dies liegen.
Dieses Verhalten deutet sehr deutlich darauf hin, dass ein Cache im Spiel ist, vermutlich wird die Verbindung gecached.
Gibt es eine Empfehlung, wie ich die MySQL noch etwas "tunen" kann.
Stück für Stück natürlich und nimm Dir Zeit ;)
-
Ist dieser Insert der erste Zugriff seit längerer Zeit auf die Tabelle? Oder hast Du vorher schon Selects gemacht? Wenn nicht, würde das auf ein Cache-Thema hinweisen.
Es kann aber auch sein, dass der INSERT zu einer Reorganisation des Indexbaums führt (sprich: viele Indexpages gespaltet werden müssen). Das dauert dann naturgemäß länger. Wieviele Rows hat die betroffene Table?
Und es kann drittens sein, dass die DB von vielen Leuten verwendet wird. Falls User A einen umfangreichen Cursor auf der Tabelle offen hat, der einen hinreichend besitzergreifenden Isolation Level verwendet, dann muss User B mit seinem INSERT ggf. warten bis der Cursor geschlossen ist. Ob MySQL Dir zum Aufspüren solcher Kollisionen eine Unterstützung durch entsprechendes Monitoring anbietet, weiß ich nicht.
Und dann kann es viertens bis dingenszigstens auch noch was ganz anderes sein. Inclusive eines Lesefehlers auf der Festplatte, den der Controller gerade relocaten muss, oder eines Admins, der gerade einen Snapshot des virtuellen SQL Servers macht. Oder eine Festplatte, die nicht im Server steckt, sondern in einem SAN, und das SAN hatte einen kurzen Schluckauf.
Rolf
-
Hallo und guten Abend,
Und dann kann es viertens bis dingenszigstens auch noch was ganz anderes sein.
Deshalb fragte ich nach dem Datenmodell und wüßte auch gerne die zum Problem gehörige Abfrage. Wenn die als relationale Abfrage über 10 Tabellen geht und auch noch Bedingungen, Procedures und Trigger berücksichtigt werden müssen, dann wäre das Verhalten doch normal!
Grüße
TS-
Insert über 10 Tabellen? Sportlich!
-
Hallo und guten Abend,
Insert über 10 Tabellen? Sportlich!
Nö, durchaus gängig und meistens leider unsportlich gelöst. :-O
Wo ist das Problem, bei einem Insert (from) über 10 Tabellen involviert zu haben, bzw. bei einem Insert auf eine einzige Tabelle weitere per Trigger o. ä. zu affektieren?
Grüße
TS-
Ok, an Trigger habe ich jetzt nicht gedacht. Damit könnte ein einsamer INSERT durchaus eine Kaskade von weiteren INSERTs quer durch die DB auslösen. Aber das würde dann nicht sporadisch geschehen und vor allem würde sich mixmastertobsi darüber nicht wundern (na guuuut - SOLLTE sich nicht wundern).
Rolf
-
-
-
-