なくなることはありません。
最大bigintは9223372036854775807です。 1000インサート/秒で106751991167日分の価値があります。私の数学が正しければ、ほぼ3億年。
分割する場合でも、オフセットを使用して、たとえば100台のサーバーがそれぞれ値の専用のサブ範囲（x*100+0を持っている）を使用します ... x*100+99 ）、不足することはありません。 1秒あたり100,000回の挿入を行う10,000台のマシンは、約3世紀でそこに到達する可能性があります。もちろん、それは何百年もの間、ニューヨーク証券取引所よりも1秒あたりのトランザクション数が多いです...
行う場合 生成されたキーのデータ型サイズの制限を超えると、新しい挿入は失敗します。 PostgreSQLでは（このPostgreSQLにタグを付けているため）bigserial 表示されます：
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)
通常のserialの場合 sequenceが原因で、別のエラーが発生します は常に64ビットであるため、キータイプをbigintに変更する必要があります。 または、次のようなエラーが発生します：
regress=# SELECT setval('serialtest_id_seq', 2147483647);
regress=# INSERT INTO serialtest (dummy) VALUES ('ham');
ERROR: integer out of range
サイトがアプリケーションのbigintの制限に達する可能性があると本当に確信している場合は、複合キー（たとえば、（shard_id、subkey））またはuuidキーを使用できます。
新しいアプリケーションでこれに対処しようとすると、時期尚早の最適化になります。真剣に、新しいアプリケーションからその種の成長まで、同じスキーマを使用しますか？またはデータベースエンジン？それともコードベース？
GUIDキーシステムでのGUIDの衝突について心配することもできます。結局のところ、誕生日のパラドックスは、GUIDの衝突が思ったよりも多いことを意味します -信じられないほど、めちゃくちゃありそうもない。
さらに、Barry Brownがコメントで指摘しているように、それほど多くのデータを保存することは決してありません。これは、トランザクション率がめちゃくちゃ高い高チャーンテーブルの場合にのみ問題になります。これらのテーブルでは、アプリケーションは、キーがゼロにリセットされたり、エントリの番号が付け直されたり、その他の対処方法に対処できる必要があります。ただし、正直なところ、トラフィックの多いメッセージキューテーブルでさえも満杯になることはありません。
参照：
真剣に、次のGootwitfacegramを作成したとしても、これは3回目のアプリケーションの書き換えの使用期限を過ぎるまで問題にはなりません...