Voilà un discours symptomatique de la méconnaissances du fonctionnement des identifiants attribués par les SGBD, l'auto-incrémenent n'est pas en cause.
La présence de trous est tout à fait normale et n'est pas spécifique à MySQL.
- les identifiants attribués par le moteur qui ne sont pas commités sont perdus
- la valeur initiale de l'identifiant est paramétrable, rien n'interdit de démarrer avec une valeur différente de zéro ou un
- le pas d'incrément est paramétrable (pour MySQL, c'est la variable AUTO_INCREMENT_INCREMENT qui pilote cet incrément, MySQL prévoit jusqu'à 65535 comme valeur d'incrément)
- certains SGBD permettent en outre de choisir au choix un incrément ou un décrément
- certains SGBD permettent également de revenir à la valeur initiale si. le compteur a atteint le max, (il faut bien sur en ce cas que les identifiants anciens aient été supprimés physiquement de la DB sinon il y aura plantage pour clef en double).
- pour éviter de solliciter le moteur de la BDD à chaque insert, certains SGBD réservent ces identifiants par plage (la taille de la plage étant paramétrable). Chaque thread ayant besoin d'un nouvel identifiant, en récupère un dans cette plage, mais, bien sur, il est possible que tel thread fasse son commit avant tel autre et enregistre ainsi un identifiant d'une valeur supérieure à celle de l'identifiant d'un autre thread qui n'a pas encore commité.
Ces deux derniers phénomènes justifient que les identifiants ne sont pas toujours chronologiques.
Partager