Schlaues UPDATE

Schlaues UPDATE

am 09.01.2006 15:38:36 von niels.froehling

Hy;

ich wollte letzt' selbst ganz schlau sein und DELETE und UPDATE mit
Erlaubnis-Klauseln ausstatten, etwa in der Form:

UPDATE abc WHEN user_darf_das;

Da die Daten in abc weitere Verknuepfungen haben hab' ich dann
angenommen das mysql_affected_rows im Falle des Verbots (durch die
Klausel) mir 0 und im Falle der Erlaubnis 1 zurueckgibt um weiteres
Bearbeiten zu stoppen. Falsch gedacht!

mysql ist noch schlauer als ich. ;) Es gibt mir auch 0 zurueck, wenn
sich nichts geaendert hat; Handbuch:

If you set a column to the value it currently has, MySQL notices this
and does not update it.

Sehr schoen, muss ich halt ueber mysql_info gehen (ich hoffe der
liefert die "matched rows" richtig?), trotzdem stellt sich mir da die
Sinnfrage: (nur mal angenommen) ich habe eine Tabelle mit 4 BLOBS in
der Groessenordnung von 20MB, wird mysql dann erstmal 20MB vergleichen
bevor es abspeichert? Wenn nicht, wenn es richtig oberschlau ist und
nur kleine Spalten vergleicht, wozu ist das ueberhaupt eingebaut
worden? Gibt's da eine Geschichte zu, Herr Holzgraefe?

Ich orientierte mich am wortwoertlichen Sinn von mysql_affected_rows,
der besagt nicht mysql_changed_rows.

Danke fuer's zuhoeren :^D
Niels

Re: Schlaues UPDATE

am 09.01.2006 16:00:21 von Rolf

> Ich orientierte mich am wortwoertlichen Sinn von mysql_affected_rows,
> der besagt nicht mysql_changed_rows.

Na, ja affected heißt wohl "betroffen", aber ich war in englich nie gut.

Wenn ich 100 Fenster habe, von denen 50 offen sind und ich jemanden bitte,
den Rest auch
zu öffnen, was sagt er dann wenn ich ihn frage, wie viele Fenster er
geöffnet hat 50 oder 100?

select count(*) from fenster;
count(*)
----------
100

update fenster set state=1;
50 rows affected;

Ich finde die Info jedenfalls besser als 100....

Gruß

Frank

Re: Schlaues UPDATE

am 09.01.2006 17:22:07 von Axel Schwenke

niels.froehling@seies.de wrote:
>
> ich wollte letzt' selbst ganz schlau sein und DELETE und UPDATE mit
> Erlaubnis-Klauseln ausstatten, etwa in der Form:
>
> UPDATE abc WHEN user_darf_das;

1. Das ist kein gültiges SQL, vermutlich meinst du WHERE ...
2. Das ist dann keine "Erlaubnis" Klausel, sondern eine Selektion

> Da die Daten in abc weitere Verknuepfungen haben hab' ich dann
> angenommen das mysql_affected_rows im Falle des Verbots (durch die
> Klausel) mir 0 und im Falle der Erlaubnis 1 zurueckgibt um weiteres
> Bearbeiten zu stoppen. Falsch gedacht!

Den Spruch mit den Pferden erspare ich uns jetzt mal...

> mysql ist noch schlauer als ich. ;) Es gibt mir auch 0 zurueck, wenn
> sich nichts geaendert hat; Handbuch:
>
> If you set a column to the value it currently has, MySQL notices this
> and does not update it.

Ja. MySQL verhält sich spezifikationsgemäß: für UPDATE und DELETE gibt
es die Anzahl der betroffenen (engl. affected) Zeilen zurück.

> Sehr schoen, muss ich halt ueber mysql_info gehen (ich hoffe der
> liefert die "matched rows" richtig?)

Ja.

> trotzdem stellt sich mir da die
> Sinnfrage: (nur mal angenommen) ich habe eine Tabelle mit 4 BLOBS in
> der Groessenordnung von 20MB, wird mysql dann erstmal 20MB vergleichen
> bevor es abspeichert?

Wobei sollte MySQL was vergleichen? Und was meinst du mit "abspeichern"?

Aber ja, wenn du eine 20MB BLOB-Spalte hast und im WHERE auf Gleichheit
testen willst, muß deine Applikation eine 20MB große Query bauen und
MySQL die 20MB vergleichen. Ob das sinnvoll ist, kannst du vielleicht
selber entscheiden. BTW, weißt du eigentlich, was ein Index ist?

> Wenn nicht, wenn es richtig oberschlau ist und
> nur kleine Spalten vergleicht, wozu ist das ueberhaupt eingebaut
> worden?

Du faselst.

> Gibt's da eine Geschichte zu, Herr Holzgraefe?

Wenn du Hartmut persönlich etwas fragen willst, dann mach das per Mail.

> Ich orientierte mich am wortwoertlichen Sinn von mysql_affected_rows,
> der besagt nicht mysql_changed_rows.

Schlage das Wörterbuch deines geringsten Mißtraues auf und suche
"affected". Vergleiche mit "changed" und "matched". Nur wo "matched"
draufsteht ist auch "matched" drin.


XL

Re: Schlaues UPDATE

am 09.01.2006 20:13:12 von niels.froehling

> Ja. MySQL verhält sich spezifikationsgemäß: für UPDATE und DELETE=
gibt
> es die Anzahl der betroffenen (engl. affected) Zeilen zurück.

Nun, vermutlich muss ich dann das UPDATE zerlegen in

- zaehle Zeilen die dem WHERE gerecht sind (matched)
- zaehle Zeilen die veraendert wurden (affected)

Eine moegliche Interpretation dieser "Black-Box" ist das 'betroffen'
ersteres bedeutet.

>> (nur mal angenommen) ich habe eine Tabelle mit 4 BLOBS in
>> der Groessenordnung von 20MB, wird mysql dann erstmal 20MB vergleichen
>> bevor es abspeichert?
>
> Wobei sollte MySQL was vergleichen? Und was meinst du mit "abspeichern"?

If you set a column to the value it currently has, MySQL notices this
and does not update it.

Das heisst mySQL fuehrt einen 'Vergleich' durch, ob die Daten sich
veraendert haben und 'speichert' diese Aenderung nur im Falle der
Ungleichheit auf einem Medium (memory, harddisk, ...). Ohne
'Speicherung' koenntest Du die Daten ja nicht wiederbekommen.

> Aber ja, wenn du eine 20MB BLOB-Spalte hast und im WHERE auf
> Gleichheit testen willst, muß deine Applikation eine 20MB große Query
> bauen und MySQL die 20MB vergleichen

Nein der BLOB steht nicht im WHERE, oder nach der Erklaerung aus dem
Handbuch doch, denn (my)SQL verhaelt sich ja so als wenn die
Gleichheits-Bedingung im WHERE staende, mit der einzigen Ausnahme, das
andere Resultate zurueckgegeben werden.
Aber nochmal die Frage: Wird dieser oben genannte 'Vergleich' mit dem
Inhalt jedes Datentypes durchgefuehrt?

> Du faselst.

Ich bin keine Maschine Axel, ich schreibe manchmal voellig redundante
posts, in denen ich meine Verwunderung zum Ausdruck bringe.

Ciao
Niels

Re: Schlaues UPDATE

am 09.01.2006 21:03:12 von niels.froehling

> Ja. MySQL verhält sich spezifikationsgemäß: für UPDATE und DELETE=
gibt
> es die Anzahl der betroffenen (engl. affected) Zeilen zurück.

Nun, vermutlich muss ich dann das UPDATE zerlegen in

- zaehle Zeilen die dem WHERE gerecht sind (matched)
- zaehle Zeilen die veraendert wurden (affected)

Eine moegliche Interpretation dieser "Black-Box" ist das 'betroffen'
ersteres bedeutet.

>> (nur mal angenommen) ich habe eine Tabelle mit 4 BLOBS in
>> der Groessenordnung von 20MB, wird mysql dann erstmal 20MB vergleichen
>> bevor es abspeichert?
>
> Wobei sollte MySQL was vergleichen? Und was meinst du mit "abspeichern"?

If you set a column to the value it currently has, MySQL notices this
and does not update it.

Das heisst mySQL fuehrt einen 'Vergleich' durch, ob die Daten sich
veraendert haben und 'speichert' diese Aenderung nur im Falle der
Ungleichheit auf einem Medium (memory, harddisk, ...). Ohne
'Speicherung' koenntest Du die Daten ja nicht wiederbekommen.

> Aber ja, wenn du eine 20MB BLOB-Spalte hast und im WHERE auf
> Gleichheit testen willst, muß deine Applikation eine 20MB große Query
> bauen und MySQL die 20MB vergleichen

Nein der BLOB steht nicht im WHERE, oder nach der Erklaerung aus dem
Handbuch doch, denn (my)SQL verhaelt sich ja so als wenn die
Gleichheits-Bedingung im WHERE staende, mit der einzigen Ausnahme, das
andere Resultate zurueckgegeben werden.
Aber nochmal die Frage: Wird dieser oben genannte 'Vergleich' mit dem
Inhalt jedes Datentypes durchgefuehrt?

> Du faselst.

Ich bin keine Maschine Axel, ich schreibe manchmal voellig redundante
posts, in denen ich meine Verwunderung zum Ausdruck bringe.

Ciao
Niels

Re: Schlaues UPDATE

am 09.01.2006 21:08:11 von niels.froehling

> Ja. MySQL verhält sich spezifikationsgemäß: für UPDATE und DELETE=
gibt
> es die Anzahl der betroffenen (engl. affected) Zeilen zurück.

Nun, vermutlich muss ich dann das UPDATE zerlegen in

- zaehle Zeilen die dem WHERE gerecht sind (matched)
- zaehle Zeilen die veraendert wurden (affected)

Eine moegliche Interpretation dieser "Black-Box" ist das 'betroffen'
ersteres bedeutet.

>> (nur mal angenommen) ich habe eine Tabelle mit 4 BLOBS in
>> der Groessenordnung von 20MB, wird mysql dann erstmal 20MB vergleichen
>> bevor es abspeichert?
>
> Wobei sollte MySQL was vergleichen? Und was meinst du mit "abspeichern"?

If you set a column to the value it currently has, MySQL notices this
and does not update it.

Das heisst mySQL fuehrt einen 'Vergleich' durch, ob die Daten sich
veraendert haben und 'speichert' diese Aenderung nur im Falle der
Ungleichheit auf einem Medium (memory, harddisk, ...). Ohne
'Speicherung' koenntest Du die Daten ja nicht wiederbekommen.

> Aber ja, wenn du eine 20MB BLOB-Spalte hast und im WHERE auf
> Gleichheit testen willst, muß deine Applikation eine 20MB große Query
> bauen und MySQL die 20MB vergleichen

Nein der BLOB steht nicht im WHERE, oder nach der Erklaerung aus dem
Handbuch doch, denn (my)SQL verhaelt sich ja so als wenn die
Gleichheits-Bedingung im WHERE staende, mit der einzigen Ausnahme, das
andere Resultate zurueckgegeben werden.
Aber nochmal die Frage: Wird dieser oben genannte 'Vergleich' mit dem
Inhalt jedes Datentypes durchgefuehrt?

> Du faselst.

Ich bin keine Maschine Axel, ich schreibe manchmal voellig redundante
posts, in denen ich meine Verwunderung zum Ausdruck bringe.

Ciao
Niels

Re: Schlaues UPDATE

am 10.01.2006 11:11:09 von Axel Schwenke

niels.froehling@seies.de wrote:
>> Ja. MySQL verhält sich spezifikationsgemäß: für UPDATE und DELETE
> gibt
>> es die Anzahl der betroffenen (engl. affected) Zeilen zurück.
>
> Nun, vermutlich muss ich dann das UPDATE zerlegen in
>
> - zaehle Zeilen die dem WHERE gerecht sind (matched)
> - zaehle Zeilen die veraendert wurden (affected)

Dafür mußt du nichts zerlegen. Diese Information liefert dir schon
mysql_info(). Du könntest aber tatsächlich zerlegen:

1. SELECT COUNT(*) ... WHERE ...
2. UPDATE ... WHERE ...

>>> (nur mal angenommen) ich habe eine Tabelle mit 4 BLOBS in
>>> der Groessenordnung von 20MB, wird mysql dann erstmal 20MB vergleichen
>>> bevor es abspeichert?
>>
>> Wobei sollte MySQL was vergleichen? Und was meinst du mit "abspeichern"?
>
> If you set a column to the value it currently has, MySQL notices this
> and does not update it.
>
> Das heisst mySQL fuehrt einen 'Vergleich' durch, ob die Daten sich
> veraendert haben und 'speichert' diese Aenderung nur im Falle der
> Ungleichheit auf einem Medium (memory, harddisk, ...). Ohne
> 'Speicherung' koenntest Du die Daten ja nicht wiederbekommen.

Ah, jetzt verstehe ich was du meinst. Ja, offensichtlich tut der
Tablehandler genau das. "Abgespeichert" wird im Fall der Übereinstim-
mung übrigens gerade nicht. Das ist ja die Optimierung dabei.

> Aber nochmal die Frage: Wird dieser oben genannte 'Vergleich' mit dem
> Inhalt jedes Datentypes durchgefuehrt?

Da im Manual nichts anderes steht, gehe ich mal davon aus, daß das
unabhängig vom Spaltentyp so ist. Besonders wichtig dürfte die
Erkennung von Schreiboperationen ohne Effekt für die Replikation sein.
Sonst würde man die ganzen NOPs vollkommen unnötig replizieren.

Weitere gute Gründe dafür: Schreiboperationen auf Tabellen invalidieren
den Query-Cache und markieren Tabellen/Tablespaces als "dirty". Wenn
man eine Schreiboperation als NOP erkennt und einfach verwirft, kann
man diese Seiteneffekte vermeiden, was zu besserer Performance führt.

>> Du faselst.
>
> Ich bin keine Maschine Axel, ich schreibe manchmal voellig redundante
> posts, in denen ich meine Verwunderung zum Ausdruck bringe.

Sag ich doch. Du faselst. Und das ist nicht das Gegenteil von Maschine.
Warum hast du das eigentlich dreimal gepostet? Nervöser Klickfinger?


XL