nicht angemeldet
Moin!
Hallo T-Rex,
Deine Antwort ist - mit Verlaub - eine Unverschämtheit sondergleichen!
Nein. DEINE Antwort ist eine Unverschämtheit.
Und zeugt auch von wenig Sachverstand, denn das hier:
Da kann man viele Probleme schon beim Design des Datenmodells - strikte Trennung von Stammdaten und Bewegungsdaten - vermeiden. Und wenn denn keine anderen Requests gleichzeitig zu erwarten sind, kann man sich die Transaktion normalerweise schenken. Da reicht es, die betroffenen Tabellen _vorher_ gegen andere Zugriffe zu sperren.
ist Bullshit!
Das Anwendungsszenario ist vollkommen "normal": In einer normalisierten Datenbank trägt man in der einen Tabelle einen Datensatz ein und erfragt die dabei erzeugte ID, und in einer zweiten Tabelle trägt man die dazu 1:n befindlichen weiteren Daten ein. Ganz offensichtlich ist unerwünscht und nicht sinnvoll, nur eine der beiden Tabellen zu befüllen. Ebenfalls ist es nicht sinnvoll, zuerst schon den einen Datensatz der ersten Tabelle für parallele Querys "sichtbar" zu machen ohne die weiteren Daten in die zweite Tabelle eingetragen zu haben.
Insofern ist es absolut normal, den Vorgang in einer Transaktion zu kapseln.
Du hättest in einer hilfreichen Antwort den guten T-Rex auf die MySQL-Dokumentation hinsichtlich der Erzeugung von auto_increment-Werten bei Transaktionen verweisen können. Beispielsweise dieser Link: https://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html
Wie man nachlesen kann, reserviert MySQL/InnoDB beim INSERT den nächsten Increment-Wert global (parallele oder später startende Transaktionen nehmen also den nächsthöheren Wert). Dieser wird dann dem neuen Datensatz zugewiesen. Bricht man die Transaktion ab (ROLLBACK), wird der Increment-Wert nicht wieder reduziert, sondern er ist verbraucht. Auf diese Weise entstehen Lücken in den IDs, was aber nichts macht, weil die ja nicht zum Durchzählen gedacht sind, sondern zum Identifizieren.
Transaktionen kann man sich nur schenken, wenn man den Vorgang in exakt einem Query durchführen kann (oder Inkonsistenzen egal sind). Bei InnoDB führt dies automatisch zu einer nur den Query umfassenden Transaktion. Es ist allerdings gelegentlich hilfreich, auch mehrere gleichartige, voneinander im Prinzip unabhängige Querys innerhalb einer einzigen Transaktion durchzuführen, denn das Kapseln hat vermutlich Performancevorteile.
Ganz verkehrt hingegen ist das Sperren der Tabelle. Damit tötet man die Performance allemal. Warum hattest du eigentlich nachgefragt, ob hoher DB-Traffic und viele parallele Connections vorliegen?
- Sven Rautenberg
Matthias Apsel