2^32で不十分な場合はどうなりますか？

テーブルに非常に多くのエントリがある場合、特定の期間（日、週、月など）にauto_increment IDが2^32で十分ではありません。
MySQLが提供する最大のデータ型では不十分な場合はどうなりますか？2^32で不十分な場合はどうなりますか？

一意のIDを必要とするテーブルに非常に多くのエントリが追加されている状況を、どのように解決すればよいのでしょうか？1つの期間内にデータ型を埋めるのですか？

MySQL（または他のシステム）内でネイティブに、ユニークなIDを無制限に、または少なくとも指数関数的に増やすことはできますか？

理想的には私は指数関数的にエントリの量を増加させ

> SELECT * FROM table; 

+---+------+ 
| a | b | 
+---+------+ 
| 1 | 1 | 
| 1 | 2 | 
| 1 | 3 | 
|...| .... | 
|...| .... | 
| 1 | 2^32 | 
| 2 | 1 | 
| 2 | 2 | 
+---+------+

のようなものを期待します。

このような状況にどのように対処していますか？
覚えておく必要があります - すべてのエントリの一意のIDを持つことです。

出典

2009-03-31 michal kralik

このような高いIDが必要なデータの種類を知りたいのですが –

主キーにBIGINTを使用できます。これは、デフォルトでは64ビットの数値です。

編集＃2：BIGINTのバイト長を変更する前に私が言ったことは間違っていたようです。 BIGINT は、8バイトの制限で固定されたです。

出典

2009-03-31 20:49:33

http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html BIGINTは8バイトに固定されていますか？ –

実際には、Rowlandは正しいと言います.BIGINTは常に64ビットです。数値データ型に関連付けることができる数値は、表示幅のみを定義し、記憶容量には影響しません。 –

私は8バイトと64ビットが同じことが分かりますか？だから、編集をホエイ？ –

128ビットキーを使用してください。あなたは非常に素早く宇宙の原子の数より多くの行を許可するので、無制限の数のキーの必要はありません。（約256ビット程度）。

出典

2009-03-31 20:47:13 Eclipse

は、自動増分主キーを使用しないでください - Wikipediaの記事から - 使用GUIDまたは類似：

各GUIDを生成している間は一意であることが保証、ユニークキーの合計数（ではありません2^128または 3.4×10^38）は大きすぎるため、という同じ数字が2回生成される可能性は無限にと小さくなります。たとえば、の観測可能な宇宙は、約5×1022個の星を含みます。すべての星はになり、次にユニークな6.8×1015のGUIDを持つことになります。

出典

2009-03-31 20:48:30 Rich

MySQLにはGUIDのネイティブサポートがあるとは思われませんでしたか？ –

次に、必要なものを処理できるRDMSを入手します。 – Eclipse

"誕生日のパラドックス"を探します。実際には、2^64 GUIDを生成した時点で、同じGUIDを2回取得する確率は約50％です。したがって、64ビットの自動インクリメントタイプを使用することに比べて利点はありません。 –

私はMySQLで自動的にそれらを生成する方法がわかりませんし、必ずしも順番である必要はありませんが、GUIDを使用することができ、アップ。

出典

2009-03-31 20:48:39 dustyburwell

私は2^64でBIGINTに移動することから始めます。 GUIDは別のオプションですが、これらを自分で「何らかの形で」格納する必要があります

出典

2009-03-31 20:51:53

キー列にchars/varcharsを使用し、キーにGUIDを使用することもできます。私は整数プライマリキーと比較してパフォーマンスペナルティが発生するかどうかは分かりません。

出典

2009-03-31 20:52:17 Kevlar

キーに別の列を追加すると、実行する必要のあるインデックススキャンの数が実質的に2倍になります（ただし、2番目の列のインデックスははるかに小さくなります）。

前述のように、VASTデータセットの最善の策は、GUID（RDBMSがネイティブにサポートしている場合）またはvarchar（16）のいずれかです。

varchar/varbinaryを使用すると便利な点は、必要に応じて将来自動的に列を展開できることです。そして、悪い点は、varchar/varbinaryは整数に比べてパフォーマンスの低いキーだということです。

出典

2009-03-31 22:05:18

この問題が発生するデータが非常に多い場合は、プライマリキーを選択することがおそらく最も懸念事項ではありません。

InnoDBエンジンを使用している場合、頻繁に検索するプライマリキー（特に検索では多くの行が返される場所）を選択するとパフォーマンスが向上します。レンジスキャンをより良くします。

出典

2009-03-31 22:13:30 MarkR

BIGINT UNSIGNEDで十分でしょうか？これは、0〜18.446.744.073.709.551.615の範囲、または1日あたり50.539.024.859.478.223のエントリ（365d/y）、1時間あたり2.105.792.702.478.259のエントリ、1分あたり35.096.545.041.304のエントリまたは584.942.417.355 /秒です。

With assumed 600 writes per second (without any reads)完全な書き込み速度でエントリを974.904.028年書くことができます。それで十分でしょう。

出典

2009-03-31 22:20:36

2^32で不十分な場合はどうなりますか？

答えて

関連する問題