90 sec für ein Update
Kalle_B
- datenbank
0 Uups ...
Kalle_B0 dedlfix
Hallöle,
habe ein Problem, das ich mir nicht erklären kann. Dieser ganz einfache Update (MySQL 5) dauert 95 sec:
<pre>94.77 sec:
#~~~~~~~~~~~~
# BUCHUNG
#~~~~~~~~~~~~
UPDATE tm_kontakte
SET
slot_nr =6
,aussteller2_id=5843
,gruppen_id =0
WHERE besucher_id =5571
AND aussteller_id=5177
AND slot_nr =0
<pre>
So habe ich die Zeit gestoppt:
list($usec, $sec) = explode(" ", microtime()); $q_start = (float)$usec + (float)$sec;
$res_buch = mysql_query( $q, $conn_id ); zeigSqlFehler( $q, $conn_id );
list($usec, $sec) = explode(" ", microtime()); $q_ende = (float)$usec + (float)$sec;
$q_dauer = round(($q_ende - $q_start) *100) /100;
if ( $q_dauer > 1.0 ) echo "<pre>".$q_dauer." sec:\n".$q."<pre>\n";
echo mysql_affected_rows( $conn_id )." Saetze gebucht<br>\n";
In der Tabelle tm_kontakte gibt es diese Keys mit den Hinweisen:
PRIMARY PRIMARY 34941 id
bes_aus UNIQUE 34941 besucher_id
aussteller_id
aus_grp_bes UNIQUE 34941 aussteller_id
gruppen_id
besucher_id
aus_bes UNIQUE 34941 aussteller_id
besucher_id
slot_nr
ausst INDEX 5823 aussteller_id
slot_nr
ausst2 INDEX 8735 aussteller2_id
slot_nr
bes_slots INDEX 11647 besucher_id
slot_nr
Die Index-Typen INDEX und UNIQUE sollten nicht gleichzeitig für die Spalte besucher\_id
gesetzt sein
Die Index-Typen INDEX und UNIQUE sollten nicht gleichzeitig für die Spalte aussteller\_id
gesetzt sein
Es sollte nicht mehr als ein Index des Typs UNIQUE für die Spalte aussteller\_id
gesetzt sein
Die Datenbank selbst ist flott. Das Stornieren dauert 0.22 sec
Lieben Gruß, Kalle
Habe den SQL- Code mal direkt in phpmyadmin eingegeben:
Betroffene Datensätze: 1 (die Abfrage dauerte 0.0004 sek.)
Hello,
Habe den SQL- Code mal direkt in phpmyadmin eingegeben:
Betroffene Datensätze: 1 (die Abfrage dauerte 0.0004 sek.)
Das gleiche Query mit denselben Datenwerten?
Und es liegt ein Unique-Index auf einer zu ändernden Spalte?
Und Du hast es erst _anschließend_ in phpmyadmin eingegeben?
Was meinst Du, wieviel dann noch geändert wurde?
Bisschen Mehr Input wäre außerdem auch nicht schlecht:
Create-Table-Statement von der Tabelle könnte schon ganz hilfreich sein.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo, Tom,
ich vermute jetzt (nach mehreren Tests), dass der Fehler gar nicht an diesem SQL- Statemant liegt, sondern bei einem anderen Programm B, das zeitgleich läuft und von diesem Programm A bei bestimmten Bedingungen ausgelöst wird.
Beim nächsten Durchlauf von Programm A dauert's dann.
Ich werde mich jetzt um Programm B kümmern ...
Kann die DB nur ein Programm zur Zeit bedienen? Dann waren die 90 sec wohl Wartezeit ...
Kalle
echo $begrüßung;
Kann die DB nur ein Programm zur Zeit bedienen? Dann waren die 90 sec wohl Wartezeit ...
Schreiben ist eine exklusive Tätigkeit. Alles andere muss dabei warten.
echo "$verabschiedung $name";
Hello,
echo $begrüßung;
Kann die DB nur ein Programm zur Zeit bedienen? Dann waren die 90 sec wohl Wartezeit ...
Schreiben ist eine exklusive Tätigkeit. Alles andere muss dabei warten.
Es wird aber nicht immer gleich auf die Platte geschrieben. Und 90sec deuten darauf hin, dass entweder ein (Dead-)Lock bestanden haben könnte, oder aber das gewählte Speichermodell für die Größe der Tabellen und der Datensätze ausgereizt ist und MySQL daher swappen musste, um z.B. den Unique Index zu reorganisieren. Da können schon mal mehrere ungünstige Umstände aufeinandertreffen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
ich vermute jetzt (nach mehreren Tests), dass der Fehler gar nicht an diesem SQL- Statemant liegt, sondern bei einem anderen Programm B, das zeitgleich läuft und von diesem Programm A bei bestimmten Bedingungen ausgelöst wird.
Beim nächsten Durchlauf von Programm A dauert's dann.
Ich werde mich jetzt um Programm B kümmern ...
Kann die DB nur ein Programm zur Zeit bedienen? Dann waren die 90 sec wohl Wartezeit ...
Mit dem Create-Statement der Tabelle könnte man mehr sagen.
Welche Engine?
Bestehen Foreign Keys?
Und dann ist es maßgeblich, wieviele Daten bereits in der Tabelle stehen.
Allerdings ist selbst bei ungünstigsten Umständen die Zeit von 95sec. für das Reorganisieren eines Index sehr lang. Dann müsstest Du schon bei voller Speicherauslastung stehen (Die Modelle kannst Du ja geringfügig einstellen) und das DBMS hat angefangen zu swappen.
Wartezeit kommt eigentlich nur in Betracht, wenn Du mit Table-Locks arbeitest.
Anderenfalls stimmt
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
echo $begrüßung;
habe ein Problem, das ich mir nicht erklären kann. Dieser ganz einfache Update (MySQL 5) dauert 95 sec:
Und dabei sieht der sehr einfach aus. Das Problem wird garantiert woanders liegen, und das kann alles und nichts sein.
Aber mal was anderes:
So habe ich die Zeit gestoppt:
[code lang=php]list($usec, $sec) = explode(" ", microtime()); $q_start = (float)$usec + (float)$sec;
Welche Uralt-Version von PHP nutzt du denn? Seit Version 5 kann man ihm true als Parameter mitgeben und bekommt ein ordentliches Ergebnis.
Die Datenbank selbst ist flott. Das Stornieren dauert 0.22 sec
Stornieren ist keine DBMS-Aktion.
echo "$verabschiedung $name";