AUTO_INCREMENTのIDカラムがオーバーフローしたらどうなるの？実例から学ぶDB設計の注意点

PHPerKaigi 2025の登壇資料です。

Transcript

1. AUTO_INCREMENTのIDカラムが オーバーフローしたらどうなるの？ 
 〜実例から学ぶ DB設計の注意点〜 
 NE株式会社
 やまもとひろや
 PHPerKaigi2025 登壇資料

2. 自己紹介
 • やまもとひろや
 • NE株式会社 開発部マネージャー
 • X: @HiroyaYamamoto1
 • Qiita: @yamamoto_hiroya
 • Zenn: yamamoto_hiroya
 • 今回NE株式会社は4名登壇！
 • 新卒採用もやってるので是非！
 ◦ https://ne-inc.jp/recruit
 ◦ 「NE株 採用」で検索！

3. 突然ですが 
 2147483647
 これ何の数字か分かりますか？ 

4. そうですね！ 
 INT型の最大値ですね！ 
 (2^31-1)

5. 4294967295
 は分かりますか？ 

6. そうですね！ 
 符号なし(UNSIGNED)
 INT型の最大値ですね！ 

7. 今回は実際に 
 UNSIGNED INTのIDカラムが
 上限を超えた 
 弊社事例を紹介します！ 

8. 目次
 • INT型（UNSIGNED INT）とは
 • 実際に起きた弊社事例
 • 対応方法と学び
 • まとめ

9. • 今回はMySQLのINT型に絞ってお話しします。
 参照: https://dev.mysql.com/doc/refman/8.0/en/integer-types.html
 INT型（UNSIGNED INT）とは

10. INT型（UNSIGNED INT）とは
 普通のINT
 (符号あり)
 UNSIGNED INT
 (符号なし)
 • 数値を入れるためのデータ型です。
 • 赤い部分がそれぞれの範囲です。
 • 通常のINTがマイナス値入るの忘れがち。
 • UNSIGNEDはマイナス値入らない=符号なしとも呼ぶ
 • 自分用: INTは約21億、符号なしは約43億
 0
 -2147483647
 4294967295
 2147483647

11. 実際に弊社で起きた事例 
 調査担当
 私
 以下エラーが出ているんですがどういう状況 か分かります？
 Duplicate entry '4294967295' for key 'sample_table.PRIMARY'

12. ふむふむ
 どうやらsample_tableのPRIMARYの
 カラム(ID)が4294967295を書き込もうとし てエラーになっているみたいだね。
 Duplicateなので既にそのID値は存在して いるみたい。
 実際に弊社で起きた事例 
 調査担当
 私

13. 実際に弊社で起きた事例 
 調査担当
 私
 じゃあIDが4294967295のレコードが
 悪さをしてそうだから
 調査してレコード削除等をすれば
 いいですかね？

14. ん〜というか
 4294967295はUNSIGNED INTの最大値 だから
 これもしかしてレコード上限
 来ちゃってるかもね
 実際に弊社で起きた事例 
 調査担当
 私

15. 実際に弊社で起きた事例 
 調査担当
 私
 え？
 UNSIGNED INTがオーバーフローすると Duplicateエラーになるんですか？

16. 実際に弊社で起きた事例 
 • ある日突然以下のエラーが発生しました。
 • Duplicate entry '4294967295' for key 'sample_table.PRIMARY'
 • データの書き込みが全て止まった。

17. 再現テスト 
 • 状況をローカル環境にて再現しました。
 • テーブル定義は以下のものを使います。
 • データは以下のようにします。

18. • この状態で新規レコードを追加しようとするとDuplicateエラーが再現し ました。
 再現テスト 

19. • 以下のような挙動をします。
 • ID値が4294967295になった。
 • 次の処理でAUTO_INCREMENTのためIDを+1しようとしたが最大値のた め4294967295のままになった。
 • IDのカラムはPRIMARYのため重複できない。
 • そのため4294967295を再びINSERTしようとしてDuplicateエラーとなっ た。
 • 補足: 現在のauto_increment値の
 確認方法
 • SHOW TABLE STATUS LIKE 
 'sample_table';
 解説

20. 調査担当
 私
 レコードの削除をしてauto_incrementの値 をリセットする？
 どう対処したか 
 約43億のレコード削除はだいぶ時間がかか るので今回は難しそう。

21. 調査担当
 私
 INT型を変えて桁数増やす？
 どう対処したか 
 ALTERにだいぶ時間がかかるので今回は難 しそう。

22. 調査担当
 私
 今のsample_tableをsample_table_oldと し、新しくsample_tableを作成する？
 どう対処したか 
 RENAMEも新しいsample_table作成もサ クッとできる。作ったらすぐそのテーブルにレ コードが書き込まれ始める。
 よし、これで行こう！

23. 解決！

24. 補足
 • ちなみに今回の例はサービス開始し約5年で発生しました。
 ◦ 1日235万レコードペース
 • そもそもそんな大量のデータをデータベースに持ちたいか？という観点か ら注意が必要です。
 • どうしても持つ場合はBIGINTで持つと2^63乗まで持てます(約900京)
 ◦ 例えばこれを10年で使い切るには1日250兆のレコードが入り続ける必要があり、ほぼ使 い切らないくらい大きい上限値だと思ってもらって良いと思います。 
 ◦ もしBIGINTを使い切ったよっていうご経験がある方がいたら是非教えてください。 

25. 学び
 • AUTO_INCREMENTで
 • PRIMARYの
 • INT型の
 • ID値が
 • 上限に行くと
 • Duplicateエラーとなる。

26. まとめ
 • 安易なID値設計は辞めましょう。
 ◦ デフォルトのINT型AUTO_INCREMENT, PRIMARYで本当に大丈夫か？
 • そもそもそのIDカラムは必要か？
 ◦ サロゲートキーか？ナチュラルキーか？ 
 • 全て考えてIDカラムを持つとして、ものすごいレコードが入る場合は BIGINTにしましょう。
 • そのテーブルは
 • 「どういう使われ方をするのか」
 • 「どういうデータが入るのか」
 • 「どれくらいの頻度で入るのか」
 • これらを考えて適切なテーブル設計をしていきましょう！