Waarom wordt er bij ON DUPLICATE KEY UPDATE de auto-increment opgehoogd?
Ik krijg zo gaten in mijn auto-increment (op zich niet heel erg maar wel irritant) en het id loopt wel erg op na veel updates. Ook gebruik ik dit id in een url wat nu niet meer als favoriet kan worden opgeslagen. Niet wenselijk dus. Heeft iemand een idee hoe dit te omzeilen?
Je zou evt eerst kunnen kijken met een query of deze entry al bestaat en dan updaten. Zoniet inserten. Het is zwaarder maar het lost in ieder geval het probleem op.
> Het is zwaarder maar het lost in ieder geval het probleem op.

Dat het zwaarder is, ben ik meteen met je eens. Ik vraag me echter af of het het probleem oplost. Ik vermoed namelijk dat het niet in deze query zit, maar heel ergens anders.
>> De uitspraak van Ger dat bij een update je autoincrement-id wordt verhoogd, klinkt logisch, maar klopt niet. ;-)

Het zit hem in ON DUPLICATE KEY update, MySQL weet van te voren niet of ie kan inserten of moet updaten.

Dit geldt overigens alleen voor InnoDb tabellen, en het is instelbaar:

SET  innodb_autoinc_lock_mode = 0
@willem. Ja die query kan beter. Ben nog beginner. Dank voor de info.
> Dit geldt overigens alleen voor InnoDb tabellen

Dat is geen onbelangrijke toevoeging... ;-)
>> Dat is geen onbelangrijke toevoeging... ;-)
Klopt, speciaal voor jou ...... ;-)

Overigens:

ON DUPLICATE KEY UPDATE
	change_date = NOW()

Dan kan je nooit weten over er daadwerkelijk iets veranderd is.
In dit geval kan je aan de change_date beter een TIMESTAMP datatype meegeven, of met MySQL 5.6.5+ een DATETIME met DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
En dan de kolom uit de query weglaten.
Ehm kunnen we het even samenvatten?
Als ik het goed begrijp:
In een InnoDb tabel geldt, wanneer er gebruik wordt gemaakt van ON DUPLICATE KEY UPDATE, dat:
1) Gefaalde inserts toch ervoor zorgen dat de AI wordt verhoogd.
2) Updates ook ervoor zorgen dat de AI wordt verhoogd (..dit heb ik nog niet kunnen testen)

Tenzij je SET innodb_autoinc_lock_mode = 0 uitvoert? Dan blijft de AI opeenvolgend?
>> Tenzij je SET innodb_autoinc_lock_mode = 0 uitvoert? Dan blijft de AI opeenvolgend?

Garantie tot aan de deur ......
Ger, ik heb het gevoel dat ik nu iets doe wat eigenlijk niet de bedoeling is en vraag me af of dat ik niet gewoon een verkeerde werkwijze heb.

Ik gebruik voor mijn site overal de AI om een record uniek te identificeren. Deze moet niet onderhevig zijn aan veranderingen aangezien ik deze ook gebruik in o.a. urls. Is het misschien beter om bij een insert de AI te hashen en op te slaan in een aparte kolom en dat aan te houden om een record uniek te maken of zeg ik nu iets heel stoms?

Dit zou m.i. bovenstaand probleem niet meer actueel maken.
> Ik gebruik voor mijn site overal de AI om een record uniek te identificeren.
> Deze moet niet onderhevig zijn aan veranderingen aangezien ik deze ook gebruik in o.a. urls.

Eenmaal uitgegeven wordt het id niet meer veranderd, tenzij je dat zelf doet. Ik zie het probleem dus niet, eigenlijk...

Reageren