Den tar inte slut.
Max bigint är 9223372036854775807. Vid 1000 inlägg/sekund är det 106751991167 dagar värt. Nästan 300 miljoner år, om min matematik stämmer.
Även om du partitionerar det, använder du offset där säg 100 servrar var och en har ett dedikerat underområde av värdena (x*100+0 ... x*100+99 ), kommer du inte att ta slut. 10 000 maskiner som gör 100 000 skär/sekund kan ta dig dit om cirka tre århundraden. Naturligtvis är det fler transaktioner per sekund än New York Stock Exchange på hundratals år solid...
Om du gör överskrider datatypstorleksgränsen för den genererade nyckeln, kommer nya infogningar att misslyckas. I PostgreSQL (eftersom du har taggat denna PostgreSQL) med en bigserial du kommer att se:
CREATE TABLE bigserialtest ( id bigserial primary key, dummy text );
SELECT setval('bigserialtest_id_seq', 9223372036854775807);
INSERT INTO bigserialtest ( dummy ) VALUES ('spam');
ERROR: nextval: reached maximum value of sequence "bigserialtest_id_seq" (9223372036854775807)
För en vanlig serial du får ett annat fel, eftersom sequence är alltid 64-bitars, så du kommer till den punkt där du måste ändra nyckeltypen till bigint eller får ett felmeddelande som:
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
Om du verkligen tror att det är möjligt för din webbplats att nå gränsen för en bigint i din applikation, kan du använda en sammansatt nyckel - säg (shard_id, undernyckel) - eller en uuid-nyckel.
Att försöka hantera detta i en ny applikation är för tidig optimering. Allvarligt talat, från en ny applikation till den typen av tillväxt, kommer du att använda samma schema? Eller databasmotor? Eller till och med kodbas?
Du kan lika gärna oroa dig för GUID-kollisioner i GUID-nyckelsystem. När allt kommer omkring innebär födelsedagsparadoxen att GUID-kollisioner är mer sannolika än du tror - på otroligt, vansinnigt osannolikt.
Dessutom, som Barry Brown påpekar i kommentarerna, kommer du aldrig att lagra så mycket data. Detta är bara ett problem för tabeller med hög churn med vansinnigt höga transaktionshastigheter. I dessa tabeller behöver applikationen bara klara av att nyckeln nollställs, poster omnumreras eller andra hanteringsstrategier. Ärligt talat, men inte ens en tabell med hög trafikmeddelandekö kommer att toppa ut.
Se:
Allvarligt talat, även om du bygger nästa Gootwitfacegram kommer detta inte att vara ett problem förrän långt efter sista användningsdatumet för din tredje applikationsomskrivning...