Tomtom: MySQL (MyISAM): Lock bei read+write

Hi

leider kommt es bei umfangreichen (minutenlangen) Anfragen meiner Cronjobs zum Generieren von Reportings vor, dass einzelne Queries (sowohl Select, als auch Update) gelockt werden.
Es sieht so aus, als würde das passieren, wenn zeitgleich auf den selben Datensatz ein Update und Select ausgeführt wird. Stimmt das und wenn ja: Wie kann ich MySQL dazu bewegen, im Problemfall die Anfragen hintereinander auszuführen statt parallel?

Die Tabellen zu kopieren und dann mit der Kopie weiterzuarbeiten, um die Originale und Update-Anfragen nicht durch Select zu stören, ist doch eine "überholte" Methode oder ist das wirklich nötig?!

Danke für Rat

  1. Hi!

    leider kommt es bei umfangreichen (minutenlangen) Anfragen meiner Cronjobs zum Generieren von Reportings vor, dass einzelne Queries (sowohl Select, als auch Update) gelockt werden.
    Es sieht so aus, als würde das passieren, wenn zeitgleich auf den selben Datensatz ein Update und Select ausgeführt wird.

    Du meinst jetzt nicht den Zustand: "Currently, you cannot update a table and select from the same table in a subquery"? Das trifft auf UPDATE mit eingebautem Subquery zu und würde mit einem Fehler geahndet werden, den du bei ordentlicher Fehlerbehandlung sehen und keine Vermutungen anstellen müsstest. Ich gehe also davon aus, dass parallel laufende Programme dein Problem verursachen.

    Stimmt das und wenn ja: Wie kann ich MySQL dazu bewegen, im Problemfall die Anfragen hintereinander auszuführen statt parallel?

    Man sollte annehmen, dass das stimmt, was im Handbuch steht. Zunächst gilt es, das Problem zu verstehen, bevor man dafür eine Lösung sucht. Wie MySQL mit Sperren umgeht, steht im Kapitel Optimizing Locking Operations, vermutlich auch Tipps, wie man da was verbessern kann.

    Die Tabellen zu kopieren und dann mit der Kopie weiterzuarbeiten, um die Originale und Update-Anfragen nicht durch Select zu stören, ist doch eine "überholte" Methode oder ist das wirklich nötig?!

    Das klingt wieder nach Update mit Subquery. Dann hilft nur eine temporäre Tabelle.

    Lo!

  2. Hello,

    leider kommt es bei umfangreichen (minutenlangen) Anfragen meiner Cronjobs

    benutzen die Queries in Schleifen?

    zum Generieren von Reportings vor, dass einzelne Queries (sowohl Select, als auch Update) gelockt werden.

    Meinst Du, die Queries können nicht ausgeführt werden, weil ein Datensatz oder eine Tabelle gesperrt ist, oder meinst Du, die Queries sperren selber die Tabellen, weil es notwendig erscheint?

    Es sieht so aus, als würde das passieren, wenn zeitgleich auf den selben Datensatz ein Update und Select ausgeführt wird.

    Für ein Update sperrt das DBMS automatisch den Datensatz (oder sogar die Tabelle nebst Indexen). Sonst würde es Durcheinander geben.

    Stimmt das und wenn ja: Wie kann ich MySQL dazu bewegen, im Problemfall die Anfragen hintereinander auszuführen statt parallel?

    Das Select würde automatisch so lange warten, bis das Update fertig ist. Die Statements werden sowieso serialisiert.

    Die Tabellen zu kopieren und dann mit der Kopie weiterzuarbeiten, um die Originale und Update-Anfragen nicht durch Select zu stören, ist doch eine "überholte" Methode oder ist das wirklich nötig?!

    Kommt ganz darauf an, was Du treibst. Ich will es mal "microsoftisch" ausdrücken. Dort unterscheidet man zwischen "Snapshot" und "Dynaset". Ein Snapshot erzeugt eine Selektion, die danach persistent ist. Es merkt sich also das Ergenis. Ein Dynaset besorgt nur die Satzzeiger auf die Datenmenge und merkt sich die Abfrageregel. Das Ergebnis ist daher transient.

    Je nachden, wie Du die Integrität der Daten wahren kannst, kannst Du mit oder ohne Sperren auskommen. Das ist vollkommen abhängig von der Statement-Gruppe.

    Ein einzelnes Statement sollte (auch bei MySQL) immer die Integrität der Daten sicherstellen, auch wenn es Subqueries enthält.

    Liebe Grüße aus dem schönen Oberharz

    Tom vom Berg

    --
     ☻_
    /▌
    / \ Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de