21


8

このような自動インクリメント列を持つ単純なテーブルを考えてください。

CREATE TABLE foo( `fooid` bigint unsigned NOT NULL auto_increment、... snipped .... 他の列PRIMARY KEY( `fooid`))ENGINE = InnoDB AUTO_INCREMENT = 10

bigintデータ型の最大値を超えないように、これをどのように再設計するのですか? 符号なしの範囲は0〜18446744073709551615です。 18446744073709551615に達するまでにどれくらいの時間がかかるのか私にはわかりませんが、Y2K問題のように、私はそれに備えておきたいのです。

3 Answer


56


ミリ秒ごとに1行挿入するとします。

18446744073709551615ミリ秒= 18446744073709552秒= 307445734561826分= 5124095576030時間= 213503982335日= 584942417年

Y2K問題のようなものではありません

1ミリ秒に_million_行を挿入しても、500年以上の間は問題ありません。

言い換えれば、心配しないでください。


18


どちらのhttp://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html [SQLモード]を使用しているかに応じて、MySQLは `AUTO_INCREMENT`の値が2つの場合のいずれかを行います。数値列は範囲外になります。 どちらの場合もエラーが発生しますが、それはさまざまな理由によるものです。

  • strictモードで* MySQLは範囲外の値を拒否し、無効な値のエラーを投げ、そして INSERT`は失敗します。 デフォルトの*非厳格モード*では、MySQLはその値をそのデータ型に許される最高値まで減らし、 `INSERT`を実行します。 しかし、 `AUTO_INCREMENT`属性がすべての可能な値をすでに使用しているので INSERT`は失敗し、このエラーになります(符号なしの `SMALLINT`の例):

MySQL said:

#1062 - Duplicate entry '65535' for key 1

ここでの `BIGINT`の例では、" 65535 "を18個のクインティリオンで置き換えてください。ただし、このエラーが本番データベースで発生したことはありそうもありません。

しかし、 TINYINT`と SMALLINT`では、アプリケーションの有効期間中に可能なキー値( `INSERT`の数)を過小評価した場合、非常に簡単に起こります。 自分のコードを変更し、データが正しく挿入されていることをテストしていると想像してください。 突然あなたのアプリケーションは上記のエラーで作業を終了します。 あなたは既知の良いコードへの変更をロールバックしますが、エラーは消えません…非常にイライラする。


2


MySQLについては知りませんが、 Postgresqlの場合、シーケンスがCYCLE / NO CYCLEであるかどうかを指定できます。 CYCLEオプションを指定して作成した場合は、再度1(または最小値)に戻り、重複キーに対してエラーが発生します。