Het standaard auto_increment-gedrag in MySQL 5.1 en later zal de auto-increment-waarden "verliezen" als de INSERT mislukt. Dat wil zeggen, het wordt elke keer met 1 verhoogd, maar maakt een verhoging niet ongedaan als de INSERT mislukt. Het is ongebruikelijk om ~750 waarden te verliezen, maar niet onmogelijk (ik heb geraadpleegd voor een site die 1500 oversloeg voor elke INSERT die slaagde).
U kunt innodb_autoinc_lock_mode=0 . wijzigen om MySQL 5.0-gedrag te gebruiken en in sommige gevallen te voorkomen dat u waarden verliest. Zie http://dev.mysql. com/doc/refman/5.1/en/innodb-auto-increment-handling.html
voor meer details.
Een ander ding om te controleren is de waarde van de auto_increment_increment config variabele. Het is standaard 1, maar u heeft dit mogelijk gewijzigd. Nogmaals, het is zeer ongebruikelijk om het in te stellen op iets hoger dan 1 of 2, maar het is mogelijk.
Ik ben het eens met andere commentatoren, autoinc-kolommen zijn bedoeld om uniek te zijn, maar niet noodzakelijkerwijs opeenvolgend. Je zou je er waarschijnlijk niet zoveel zorgen over moeten maken, tenzij je de autoinc-waarde zo snel verhoogt dat je buiten het bereik van een INT zou kunnen komen (dit is mij overkomen).
Hoe heb je het precies opgelost waarbij je 1500 voor altijd invoegen overslaat?
De oorzaak van het mislukken van INSERT was dat er een andere kolom was met een UNIEKE beperking erop, en de INSERT probeerde dubbele waarden in die kolom in te voegen. Lees de handleiding waarnaar ik heb gelinkt voor details over waarom dit belangrijk is.
De oplossing was om eerst een SELECT-actie uit te voeren om te controleren op het bestaan van de waarde voordat deze werd INSERT. Dit druist in tegen de algemene wijsheid, namelijk om gewoon de INSERT te proberen en elke dubbele sleuteluitzondering af te handelen. Maar in dit geval zorgde het neveneffect van de mislukte INSERT ervoor dat een auto-inc-waarde verloren ging. Door eerst een SELECT uit te voeren, werden bijna al dergelijke uitzonderingen geëlimineerd.
Maar jij ook een mogelijke uitzondering moet afhandelen, zelfs als u eerst SELECTEERt. Je hebt nog steeds een raceconditie.
Je hebt gelijk! innodb_autoinc_lock_mode=0 werkte als een tierelier.
In jouw geval zou ik willen weten waarom zoveel inserts falen. Ik vermoed dat je, net als veel SQL-ontwikkelaars, niet controleert op successtatus nadat je je INSERT's in je AJAX-handler hebt gedaan, dus je weet nooit dat zoveel van hen falen.
Ze falen waarschijnlijk nog steeds, je verliest alleen geen auto-inc-ID's als bijwerking. U moet echt vaststellen waarom er zoveel storingen optreden. Mogelijk genereert u onvolledige gegevens of voert u veel meer transacties uit dan nodig is.