MySQL und Insert
-
nabend,
ich hab eine Frage zu MySQL:
Wenn ich zeitgleich viele INSERTS auf ein und den selben DS mache und ein bestimmtes Feld jedes mal um 1 inkrementiere, habe ich das bisher immer auf folgende Art gelöst. Bestimmten Feld aus DS auslesen, inkrementieren und per Update wieder einfügen.
Zur selben Zeit wird dieser DS aber auch oft ausgelesen(mit jedem Auslesen des DS, wird das Feld inkrementiert).
Gibt es eine bessere Lösung? Sprich performanter? Mir war so, als ob Selects Vorang vor Inserts haben? Werden dann die Inserts temporär zwischen gespeichert, bevor sie in die Tabelle können?
Vielen Dank zu später Stunde
-
ich verstehe nicht ganz wo das problem liegt??
Aber das auslesen und anschliesende update ist schon mal käse, geht auch in einem update:"UPDATE my_table SET counter=counter+1 WHERE ..."
-
Sorry, schlecht formuliert!
Also es handelt sich dabei um eine Bildergalerie(website). Bei jedem Besucher der sich das Bild anguckt(also die select-Abfrage), soll das Feld pic_views inkrementiert werden.
Es ist auch weniger ein Problem(es funzt ja auch), mich würde nur interessieren, wie so ein System und extremen Bedingungen arbeitet und ob es da bessere Lösungen gibt? Klicks temporär speichern und per Cron dann Stündlich aktualisieren??
Trotzdem schon mal netten Dank!
-
naja um nur die klicks mitzuzählen brauchst du nichts aufwendiges, ist doch egal wenn mehrere SELECT ansfragen gleichzeitig anstehen.
Ruf in deinem script folgendes auf:
1. hohle die daten des bildes "SELECT pic_data,counter FROM pic_table WHERE ..."
2. incrementiere den counter "UPDATE pic_table SET counter=counter+1 WHERE ..."Es ist völlig egal wieviel nun gleichzeitig darauf losstürem, incrementiert wird immer.
Wenn du darauf hinauswillst das der counter in der select anweisung ne kleine abweichnung haben kann, da ja rein theoretisch ein andere script ja zwischen SELECT und UPDATE stecken könnte und dadurch 1 click zu wenig angezeigt wird ( LOL
) gibt natürlich auch ne lösung:
"SELECT pic_data,counter FROM pic_table WHERE ... FOR UPDATE"
"UPDATE pic_table SET counter=counter+1 WHERE ..."Das hier setzt jetzt eine sperre ( das "FOR UPDATE"). Nun muss also das 2. script das versucht aus der tabelle zu lesen wärend das 1. ziwschen SELECT und UPDATE ist warten bis das update durch ist.
^^ ist aber käse für deinen einsatz, da es schie* egal ist ob 1 klick mehr oder weniger angzeigt wird :p
-
Danke!
-
Es ist nicht egal.
Select geht vor Insert.
MYSQL speichert dann die Insert zwischen und verarbeitet sie wenn Zeit ist.
Bekommt aber MYSQL nie Zeit (Pausenlos Selects) dann läuft dieser Zwischenspeicher über.Größe des Zwischenspeicher für INSERT/UPDATE ist eine MYSQL-System-Variable
-
Danke Unix-Tom!
Würdest Du mir die "SELECT ... FOR UPDATE" oder lieber zum tmp speichern in einer speziellen Tablle raten(diese dann per Cron in die Eigentliche speichern)? Oder doch eine ganz andere Lösung?
Danke
-
So einfach ist das nicht.
Ich mache es so: Sollte ein Statement fehlschlagen schreibe ich es in eine Datei die ich dann per Daemon auslesen. Darin versuche ich das Statement solange auszuführen bis es klappt.Jetzt muss man sich aber dann mit der datei beschäftigen da diese ja größer wird und man nicht löschen kann.
-
Die Gallery möchte ich mal sehen, dass MySQL keine Zeit mehr für INSERTs findet
-
Kann schon sein das er das nicht hat aber wenn er dies zum Spass macht dann sollte er es so machen das es in jedem Fall geht.
Dies ist auch der Grund warum große Seiten für SELECT andere Server nehmen als für die UPDATES/INSERTS.
Da blockieren die SELECT die INSERTS nicht
-
geeky schrieb:
Die Gallery möchte ich mal sehen, dass MySQL keine Zeit mehr für INSERTs findet
Man weiß ja nie was noch kommt...
Nee, aber mal im Ernst: Es ging mir speziell darum, wie man solche Probleme lösen kann und auch sollte. Zur Veranschaulichung habe ich nur oben genanntes Beisspiel genommen.
Dank Unix-Tom weiss ich das jetzt
Also besten Dank an alle die sich darüber Gedanken gemacht haben