06. januar 2005 - 16:55Der er
10 kommentarer og 1 løsning
Probs med auto increment
Jeg har arbejdet med en version af MySQL (3.23.52), som opførte sig mærkeligt mht auto increment.
Jeg havde en tabel med et felt 'id' af typen int(11) som primary key med auto increment. I denne tabel oprettede jeg manuelt en record med id -1. Dette bevirkede at den næste record, der blev indsat, fik tildelt et id med en meget høj værdi (noget med 24 mill), og at der derefter ikke kunne oprettes flere records, da MySQL prøvede at tildele det samme id (24 mill) til næste record.
Hele missæren kom sig som sagt af at jeg havde en record med id -1, og jeg spekulerer på om dette er en bug i MySQL (det virker i en senere version 4.1), eller om man skal regne med at auto increment opfører sig sådan og derfor ikke indsætte negative værdier, eller overhovedet manuelt definere værdier i et felt med auto increment?
(Jeg har i øvrigt lavet en work-around så det er ikke en decideret løsning jeg søger, mere en forklaring :-)
Den meget høje værdi har sandsynligvis vis nærmere været i nærheden af 2,4 mia., eller præcis maksimalværdien for en unsigned integer. Det MySQL ikke kan lide er nok den negative værdi - jeg tror i det hele taget ikke, at negative værdier regnes for gyldige. At man manuelt kan sætte værdier i en autonummereret kolonne er noget specielt for MySQL - MS SQL tillader det f.eks. ikke, og indsætter pr. automatik kun positive tal.
Prøv at undlade negative værdier og se, om ikke det virker.
Ok. Som sagt har jeg lavet en løsning, hvor jeg undlader autonummerering (dejligt at få nogle danske udtryk knyttet på) som bare finder MAX(id) og lægger én til. En lidt interimistisk løsning, som kan 'knække', men den virker for det konkrete projekt. Men jeg vil lige tage det in mende til næste projekt :-) Ved du i øvrigt om man kan få returneret autonummereringen uden at skulle lave endnu en forespørgsel, efter at man har foretaget en INSERT?
Værdien er ca. 2.1 mia. som er max. værdi for en signed integer.
Det er de negative tal der giver problemer. Man behøver ikke engang indsætte et negativt tal. Hvis man sætter auto increment til at starte ved -1000, så bliver første række 2.1 mia. og anden række fejler.
-----
SELECT MAX(id)+1 FROM tabel
duer ikke i en flerbruger sammenhæng - og må bestemt frarådes
Arne: På samme vis som MAX(id)+1 FROM tabel ikke virker, er der så ikke samme problem i SELECT LAST_INSERT_ID efter at have brugt en INSERT? Der er vel altid en risiko for at der er ændret i tabellen imellem to queries?
Ah, smukt :-) Havde slet ikke gennemskuet at connections havde den funktion. Tak for hjælpen. Jeg vil ændre lidt på koden, og så håber jeg at du klarer dig uden point for denne gang, da et svar er accepteret. :-)
Mht. MySQL og flere brugere. Har du et link til noget generel reference, for jeg kunne komme i tanker om flere situationer, hvor flere tråde, der har adgang til den samme data kan lave rav i den.
Jeg har ikke lige et link til MySQL & concurrency problemer.
Men du må kunne finde noget generelt om databaser & concurrency problemer.
Vær opmærksom på at MySQL har flere forskellige tabel typer.
MyISAM tabeller er super hurtige men understøtter ikke transaktioner. Og derfor vil du relativt nemt kunne få concurrency problemer.
InnoDB tabeller understøtter transaktioner og hvis du bruger dem og sætter transaction isolation level til serializable, så er du relativt godt beskyttet mod concurrency problemer.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
