Kalle_B: 90 sec für ein Update

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

  1. Habe den SQL- Code mal direkt in phpmyadmin eingegeben:

    Betroffene Datensätze:  1 (die Abfrage dauerte 0.0004 sek.)

    1. 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

      --
      Nur selber lernen macht schlau
      http://bergpost.annerschbarrich.de
      1. 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

        1. 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";

          1. 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

            --
            Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
        2. 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

          --
          Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
  2. 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";