MySQL の (big)int 型とストレージの微妙な関係 : にぽたん研究所

以前、MySQL について、こんな事を書いた事がありました。 MySQL の auto_increment が duplicate key になる恐れint(10) unsigned で、auto_increment だと、1 〜 4,294,967,295 までしかインクリメントしないから、仮にもし「1 日 100 万レコード」ずつ INSERT されたら 11 年と 9 ヶ月ちょっと経つと duplicate key が発生してしまう！！だからと言って、int 型だと恐いよー！ってヒヨって bigint(20) unsigned で auto_increment なんかしたとしても、1 〜 18,446,744,073,709,551,615 までしかインクリメントしないから、仮にもし「1 日 100 億レコード」ずつ INSERT された日にゃ 5,050,546 年 11 ヶ月と

[at_yasu]

「そう考えると、1.6TB のハードディスクが最低でも 213,885,025 基必要っていう容量です」

[yodelx]

“「漢 (おとこ) は黙って bigint(20) unsigned auto_increment だろ」とか言う漢が、いずれこの 21 世紀をグイグイ引っぱって行く”

[questb]

mysql db

[s025236]

auto_incrementでunsigned付けない理由がなくintだと足りない事はある。bigintでも若い番号は消して運用してればこんな事起きない。

[nilab]

MySQL の (big)int 型とストレージの微妙な関係 - にぽたん研究所 : 「int 型で auto_increment なカラムだけを全部ファイルにリダイレクトしたとして、どのぐらいの記憶領域が必要なのか」

[peketamin]

"「漢 (おとこ) は黙って bigint(20) unsigned auto_increment だろ」とか言う漢が、いずれこの 21 世紀をグイグイ引っぱって行くんだろうなという気がしてやみません。そんな「漢テーブル」に…"

[t2y-1979]

bigint すげーな

[blog0009]

MySQL の (big)int 型とストレージの微妙な関係 - にぽたん研究所 -