Kom ihåg mig?
Home Menu

Menu


Få MySQL att sluta resetta auto_increment?

 
Ämnesverktyg Visningsalternativ
Oläst 2013-06-12, 14:31 #11
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
Standard Autoincrement

Hej Jesper!
Jag tycker din fråga verkar spännande och det kan finnas en potentiell bugg i någon version av Mysql som du har hittat.

Jag kunde inte låta bli att prova med en egen tabell i en Mysql med InnoDB motor. Lade in några poster som hade en auto inkrementell räknare i sig. Därefter startade jag om tjänsten för att se om räknaren var nollställd. Det var den inte.

Du skriver att din tabells data bara existerar några timmar eller kanske bara några dagar. Hur töms den? Men truncate nollställs såklart räknaren men inte med delete.

Tycker problemet verkar konstigt snudd på barockt. Kan du om du orkar skriva ned de olika steg du gör för att "tappa" räknarens värde.

Här är min tabell och de inställningar jag körde med (efter omstart av tjänst är värdet 5 inte 1). Hur ser din tabell ut?
CREATE TABLE `slask` (
`counter` int(11) NOT NULL AUTO_INCREMENT,
`someValue` char(50) COLLATE utf8_swedish_ci DEFAULT NULL,
PRIMARY KEY (`counter`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci

Serversetup
Mysql 5.5.28
Ubuntu 12.04

Sen skulle du kunna göra så att du faktiskt sparar last_insert_id i en annan tabell som du sedan alltid hämtar ifrån och sedan ändrar din tabell med ALTER TABLE tbl AUTO_INCREMENT = Ditt värde;
Men det låter som ett löjligt sätt att lösa ett okänt problem på. Det är nog bättre med en djupdykning och ta reda på orsaken.

Vänligen
Cornelii
corneliisandberg är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-12, 16:12 #12
lubic lubic är inte uppkopplad
Medlem
 
Reg.datum: Aug 2005
Inlägg: 205
lubic lubic är inte uppkopplad
Medlem
 
Reg.datum: Aug 2005
Inlägg: 205
Tror inte det är en bugg, utan det är så det är tänkt att fungera, om jag inte är helt fel ute?. Alltså om du skapar upp några poster så att auto_increment ökar och sedan tar du bort dessa rader med delete så att tabellen töms (eller åtminstone så att de rader med högst id försvinner). När du sedan startar om servern och stoppar i nya rader så har auto_increment nollställts till den rad med högst id. Jag har inte själv testat detta men det är det som verkar vara "problemet"?
lubic är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-13, 09:11 #13
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
Hej Lubic!
Gör följande.

InnoDB
1. Ta bort en post från tabellen. Inkrementellt värde ser ut att vara samma som innan. Dvs om pekar var på position 5 så står det fortfarande 5.
2. service mysql restart (t.ex. omstart av databasen)
3. Inkrementellt värde har nu minskat till 4

MyIsam (ändra samma tabell till MyIsam)
Samma procedur som ovan behåller räknarens inkrementella värde även efter omstart .

Se länk.

Citat:
InnoDB uses the in-memory auto-increment counter as long as the server runs. When the server is stopped and restarted, InnoDB reinitializes the counter for each table for the first INSERT to the table, as described earlier.
corneliisandberg är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-13, 13:30 #14
lubic lubic är inte uppkopplad
Medlem
 
Reg.datum: Aug 2005
Inlägg: 205
lubic lubic är inte uppkopplad
Medlem
 
Reg.datum: Aug 2005
Inlägg: 205
Precis, då är det som jag har uppfattat det, och alltså inte en bugg som du misstänkte?
lubic är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-13, 20:11 #15
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Jag skulle säga att det är en bugg i kravspecifikationen, för autoincrement ska inte fungera som Max(PK) utan ska bevara sitt värde vid omstart.
Conny Westh är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-14, 10:04 #16
Westmans avatar
Westman Westman är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Jun 2004
Inlägg: 4 021
Westman Westman är inte uppkopplad
Klarade millennium-buggen
Westmans avatar
 
Reg.datum: Jun 2004
Inlägg: 4 021
Citat:
Ursprungligen postat av ConnyWesth Visa inlägg
Jag skulle säga att det är en bugg i kravspecifikationen, för autoincrement ska inte fungera som Max(PK) utan ska bevara sitt värde vid omstart.
Instämmer, jag skulle bra gärna vilja veta hur de tänkte när de valde den här funktionaliteten.
Westman är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-14, 10:57 #17
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
Mmm håller med Conny och Westman. En eye-opener efter 20 år i branschen, inte så vanligt numera.

Men okej nu känner vi till skillnaden och kanske kan InnoDBs sätt att ej behålla inkrementellt värde också användas av oss nu när vi har vetskapen om denna feature.

Ha det gott nu i helgen!
corneliisandberg är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-14, 17:57 #18
JesperA JesperA är inte uppkopplad
Medlem
 
Reg.datum: Jul 2008
Inlägg: 214
JesperA JesperA är inte uppkopplad
Medlem
 
Reg.datum: Jul 2008
Inlägg: 214
Lite blandade känslor att jag stötte på denna "buggen"/speccen, hade gärna varit lyckligt ovetande om detta beteendet, enda jag kommer på varför dom inte vill spara värdet annat än i ram är för att minska overheaden vid användandet av auto_increment, det skulle ju annars bli en extra skrivning till disk för varje increment värdeökning, men ja, jag hade gärna sett att man kunde välja beteendet åtminstonde så den faktiskt sparar värdet.


Jag har nu bytt så att min arkiverande tabell sköter auto_increment och så får min tillfälliga tabell styras av den, inga problem, kunde lika gärna varit så från början egentligen.

Vill inte byta till MyISAM heller, rätt skönt att köra transaktioner i InnoDB.

Iaf, kommer inte manuellt spara auto_increment värdet, nu vet jag ju om detta beteendet och det är sällan jag startar om mysql service eller servern, sällan den krashar också, så jag kan ju manuellt sätta auto_increment värdet om något av det inträffar.


Men som sagt, jag hade hellre sett att det åtminstonde fanns ett val att spara auto_increment när man kör InnoDB, blev sjukt förvånad när jag vaknade en morgon och kollade loggarna och dom var sprängfyllda med:

"SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '402' for key 'PRIMARY'"

Jag har alltid till 100% litat blint på att auto_increment skall garantera ett unikt värde, men i mitt scenario (om än går att undvika) så garanterades det inte

Senast redigerad av JesperA den 2013-06-14 klockan 18:00
JesperA är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-14, 20:54 #19
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
corneliisandberg corneliisandberg är inte uppkopplad
Nykomling
 
Reg.datum: Oct 2012
Inlägg: 33
Jesper: Lika förvånad jag. Har också blint trott på att värdena är unika och aldrig kan förekomma mer än en gång. Nu känns det lite som att varje gång vi vaknar på morgonen har vi fått ett nytt personnummer att lära oss.
corneliisandberg är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-06-20, 00:05 #20
bya bya är inte uppkopplad
Medlem
 
Reg.datum: Apr 2003
Inlägg: 103
bya bya är inte uppkopplad
Medlem
 
Reg.datum: Apr 2003
Inlägg: 103
hibernate tex, som mappar javaklasser till databas, använder en separat tabell för "sequence" , asså ett nästa värde... det har nog sina anledningar.
bya är inte uppkopplad   Svara med citatSvara med citat
Svara


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 22:25.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
 
Copyright © 2017