Es ist ein BUG

[Tom]

Hello,

bei mysql begebe ich mich immer ein wenig aufs glatteis. aber grundsätzlich würde ich sagen, ist das kein bug, dass autoincrementwerte durch das löschen von datensätzen mit delete nicht zurück gesetzt werden,

Da es sich hier um eine zugesicherte Eigenschaft handelt, die bei MySQL 3.23.55 auch noch funktioniert, ist es ein Bug. Es gibt immerhin auch Applikationen, die sich auf zugesicherte Eigenschaften einer Software verlassen müssen.

http://dev.mysql.com/doc/mysql/de/CREATE_TABLE.html

und da ungefähr in der Mitte:

<cite>
Wenn Sie alle Zeilen in der Tabelle mit DELETE FROM tabelle (ohne ein WHERE) im AUTOCOMMIT-Modus löschen, fängt die Folge bei allen Tabellentypen von Neuem an. HINWEIS: Es darf nur eine AUTO_INCREMENT-Spalte pro Tabelle geben und diese muss indiziert sein. MySQL-Version 3.23 funktioniert darüber hinaus nur korrekt, wenn die AUTO_INCREMENT-Spalte nur positive Werte hat.
</cite>

Es ist der Link, den Vinzenz schon gepostet hatte (Dank nochmal dafür).

Die Eigenschaft, den Initialwert für Autoincrement zurückzusetzen, halte ich auch für sehr nützlich. Man hätte dafür aber ggf. eine eigene Funktion einführen können.

Oder man müsste dafür sorgen, dass man beim Truncate das Lock auf die Tabelle nicht verliert.

Ich probiere aber nun noch eine andere Vorgehensdweise aus:

Schleifenbeginn -->

Truncate temp; (das geht ja schief, wenn der table locked ist)
  lock tables table1 write, tabel2 write, temp write;

andere Statements durchführen

unlock tables;

<-- Schleifenende

Das dumme daran ist eben, dass eigentlich die ganze Schleife gebunden bleiben muss. Ich muss mir nun also zusätzliche Sicherheite überlegen, dass in einem Locking-Gap keine Operationen (anderer Benutzer) dazwischenkommen können, die die Integrität gefährden.

Das treibt die Performance des Scriptes enorm in die Knie.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom