20

これに対する良い答えを自分で想像することはできないので、ここで質問することを考えました。私の心の中で、 MySQLテーブルのAUTO INCREMENT PRIMARY ID列が使い果たされたらどうなるのだろうといつも思っています。

たとえば、2 つの列を持つテーブルがあるとします。ID ( auto increment, primary, BIGINT unsigned) とDESC ( ) VARCHAR 255。確かにたくさんあることは知ってBIGINTいますが、限界に達する可能性があります。IDが限界に達した場合のシナリオをどのように処理しますか? 別のサーバーが必要ですか? その場合、どうすれば同期できますか？これは正しい方法ですか？洞察の友人。

4

4 に答える 4

54

尽きません。

最大 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)

は常に 64 ビットであるため、通常のserial場合は別のエラーが発生します。そのため、キーの種類を次のように変更するか、次のようなエラーが発生する必要があります。sequencebigint

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 回目のアプリケーションの書き直しの使用期限を過ぎるまで問題にはなりません...

于 2012-10-30T05:14:57.847 に答える
14

Bigintは2^63または約10^19です。データベースのベンチマークは、標準化されたTPC-Cベンチマークを使用して、数年前に大流行していました。

ご覧のとおり、リレーショナルデータベースの最速のリレーショナルスコアは30,000,000（1分あたり3x10 ^ 7トランザクション）です。プロファイルには多くの読み取りが含まれることに注意してください。同じシステムが1分あたり30,000,000行を書き込む可能性はほとんどありません。

ただし、 BigIntを使い果たすには、約3x10^11分かかります。私たちが理解する時間測定では、それは600万年のようなものです

ERROR 1467 (HY000): Failed to read auto-increment value from storage engine

不足した場合は、上記のエラーメッセージが表示され、主キーのGUIDに移動します。 2 ^ 128、地球上にはその数よりも少ないデジタルビットがあります（数千億倍）。

于 2012-10-30T05:33:06.860 に答える
2

Autoincrement がフィールド サイズの制限に達すると、INSERT はエラーを生成します。

実際には、次のタイプのエラーが発生します。

ERROR 1467 (HY000): Failed to read auto-increment value from storage engine

詳細については、次をご覧ください。

http://dev.mysql.com/doc/refman/5.1/en/example-auto-increment.html

于 2012-10-30T05:17:19.300 に答える
2

大規模なデータ セットでは、増加する数値をキーとして使用しません。暗黙の上限があるだけでなく、複数のサーバーがある場合に問題が発生します。増分であるため、主キーが重複するリスクがあるためです。

MySQL でこの制限に達すると、次のような不可解なエラーが発生します。

Error: Duplicate entry '0' for key 1

一意の ID または生成したその他のシーケンスを使用することをお勧めします。MySQL はシーケンスをサポートしていませんが、postgresql はサポートしています。

于 2012-10-30T05:16:01.697 に答える