Le comportement par défaut d'auto_increment dans MySQL 5.1 et versions ultérieures "perdra" les valeurs d'auto-incrémentation si l'INSERT échoue. C'est-à-dire qu'il incrémente de 1 à chaque fois, mais n'annule pas une incrémentation si INSERT échoue. Il est rare de perdre ~750 valeurs mais pas impossible (j'ai consulté un site qui sautait 1500 pour chaque INSERT réussi).
Vous pouvez modifier innodb_autoinc_lock_mode=0 pour utiliser le comportement de MySQL 5.0 et éviter de perdre des valeurs dans certains cas. Voir http://dev.mysql. com/doc/refman/5.1/en/innodb-auto-increment-handling.html
pour plus de détails.
Une autre chose à vérifier est la valeur de auto_increment_increment variable de configuration. C'est 1 par défaut, mais vous avez peut-être changé cela. Encore une fois, il est très rare de le définir sur quelque chose de supérieur à 1 ou 2, mais possible.
Je suis d'accord avec les autres commentateurs, les colonnes autoinc sont destinées à être uniques, mais pas nécessairement consécutives. Vous ne devriez probablement pas vous en soucier autant à moins que vous n'avanciez la valeur autoinc si rapidement que vous pourriez sortir de la plage d'un INT (cela m'est arrivé).
Comment avez-vous résolu le problème en sautant 1 500 insertions à jamais ?
La cause de l'échec de l'INSERT était qu'il y avait une autre colonne avec une contrainte UNIQUE dessus, et l'INSERT essayait d'insérer des valeurs en double dans cette colonne. Lisez la page de manuel à laquelle j'ai lié pour plus de détails sur la raison pour laquelle cela est important.
Le correctif consistait à effectuer d'abord un SELECT pour vérifier l'existence de la valeur avant de tenter de l'INSERER. Cela va à l'encontre de la sagesse commune, qui consiste simplement à essayer l'INSERT et à gérer toute exception de clé en double. Mais dans ce cas, l'effet secondaire de l'échec de l'INSERT a entraîné la perte d'une valeur d'auto-inc. Faire d'abord un SELECT a éliminé presque toutes ces exceptions.
Mais vous aussi devez gérer une éventuelle exception, même si vous avez d'abord SELECT. Vous avez toujours une condition de concurrence.
Vous avez raison! innodb_autoinc_lock_mode=0 a fonctionné comme un charme.
Dans votre cas, je voudrais savoir pourquoi tant d'inserts échouent. Je soupçonne que, comme de nombreux développeurs SQL, vous ne vérifiez pas l'état de réussite après avoir effectué vos INSERT dans votre gestionnaire AJAX, vous ne savez donc jamais que tant d'entre eux échouent.
Ils échouent probablement toujours, vous ne perdez tout simplement pas les identifiants auto-inc comme effet secondaire. Vous devriez vraiment diagnostiquer pourquoi tant d'échecs se produisent. Vous pourriez soit générer des données incomplètes, soit exécuter beaucoup plus de transactions que nécessaire.
