Med select max(id) + 1 två sessioner som infogas samtidigt kommer att se samma nuvarande max-ID från tabellen, och båda infogar samma nya ID-värde. Det enda sättet att använda detta på ett säkert sätt är att låsa bordet innan transaktionen påbörjas, vilket är smärtsamt och serialiserar transaktionerna. (Och som Stijn påpekar kan värden återanvändas om den högsta posten raderas). Använd i princip aldrig detta tillvägagångssätt. (Det kan ibland finnas en övertygande anledning att göra det, men jag är inte säker på att jag någonsin har sett en).
Sekvensen garanterar att de två sessionerna får olika värden, och ingen serialisering behövs. Det kommer att prestera bättre och vara säkrare, lättare att koda och lättare att underhålla.
Det enda sättet du kan få dubbletter av fel med hjälp av sekvensen är om poster redan finns i tabellen med ID:n över sekvensvärdet, eller om något fortfarande infogar poster utan att använda sekvensen. Så om du hade en befintlig tabell med manuellt inmatade ID:n, säg 1 till 10, och du skapade en sekvens med ett standardvärde för start med 1, skulle den första infogningen som använder sekvensen försöka infoga ett ID på 1 - som redan finns . Efter att ha provat det 10 gånger skulle sekvensen ge dig 11, vilket skulle fungera. Om du sedan använde max-ID-metoden för att göra nästa infogning skulle det använda 12, men sekvensen skulle fortfarande vara på 11 och skulle också ge dig 12 nästa gång du ringde nextval .
Sekvensen och tabellen är inte relaterade. Sekvensen uppdateras inte automatiskt om ett manuellt genererat ID-värde infogas i tabellen, så de två tillvägagångssätten blandas inte. (Bland annat kan samma sekvens användas för att generera ID:n för flera tabeller, som nämnts i dokumenten).
Om du byter från ett manuellt tillvägagångssätt till ett sekvensupplägg måste du se till att sekvensen skapas med ett start-med-värde som är högre än alla befintliga ID:n i tabellen, och att allt som gör en infogning använder sekvensen bara i framtiden.