mysql_insert_id

[dedlfix]

Hi!

INSERT INTO test(bla) VALUES (1),(2),(3)
Du könntest nach dem insert die ids abfragen:
select id from test where bla in (1,2,3)
Da hast du halt zwei Abfragen statt ein paar hundert.
Die sind aber auch nicht automatisch atomar gekapselt. Man müsste also schon genau darüber nachdenken, ob ggf. ein anderer Prozess schon wieder mit den Daten herumgespielt hat.

Hier braucht man eigentlich gar nicht weiterzudenken, weil das nicht die Lösung für das eigentliche Problem war (was aber kein Vorwurf an Alexander Brock ist, denn die etwas sehr vereinfachten Darstellung von Toni war missverständlich).

Da hilft dann wieder die eigene eindeutige Transaktionsnummer im Tabellendesign. Solange die noch gesetzt ist, darf kein anderer Prozess mit dem Datensatz arbeiten.
Die Entfernung der Transaktionsnummer ist immer der letzte Schritt, wenn alle datenverändernden Arbeiten erledigt sind.

Baust du hier das vorhandene Locking-System mit Daten nach?

Alternativ könnte man sich auch mit einem (virtuellen) Lock auseinandersetzen.

http://dev.mysql.com/doc/refman/5.1/en/lock-tables.html
http://dev.mysql.com/doc/refman/5.1/en/miscellaneous-functions.html#function_get-lock

Ich sehe das nicht als Alternative sondern als eine sinnvolle Lösung an. Wenn es denn aufgrund einer konkreten Aufgabenstellung überhaupt notwendig ist. Wenn es hingegen wirklich auf transkationsfeste Vorgänge ankommt, sollte man nicht am falschen Ende sparen und lieber InnoDB verwenden, als sich mit irgendwelchen Metadaten Transaktionen für Arme nachzubauen.

Und hier sind noch einige Stellen für Dedlfix:

http://dev.mysql.com/doc/refman/5.1/en/internal-locking.html
http://dev.mysql.com/doc/refman/5.1/en/table-locking.html
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_concurrent_insert

Das Thema ist wohl bei MySQL noch nicht wirklich durch, denke ich.
Während andere Systeme teilweise Row-Locking beim Insert unterstützen, operiert MySQL immer noch mit Table-Locking.

Hast du die verlinkten Stellen auch gelesen? Je ein Zitat vom ersten und zweiten Link:

"MySQL uses table-level locking for MyISAM, MEMORY, and MERGE  tables, and row-level locking for InnoDB tables."

"To achieve a very high lock speed, MySQL uses table locking (instead of page, row, or column locking) for all storage engines except InnoDB and NDBCLUSTER."

Es hat also nichts mit "noch" zu tun sondern mit einer Design-Entscheidung pro Geschwindigkeit bei der MyISAM-Engine.

Lo!