Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AUTO_INCREMENTのIDカラムがオーバーフローしたらどうなるの?実例から学ぶDB設計...
Search
yamamoto-hiroya
March 18, 2025
Technology
1
540
AUTO_INCREMENTのIDカラムがオーバーフローしたらどうなるの?実例から学ぶDB設計の注意点
PHPerKaigi 2025の登壇資料です。
yamamoto-hiroya
March 18, 2025
Tweet
Share
More Decks by yamamoto-hiroya
See All by yamamoto-hiroya
パフォーマンスを改善するには仕様変更が1番はやい
yamamotohiroya
16
7k
プルリクサイズが大きいと警告してくれる君を作りました!
yamamotohiroya
1
440
安全にプロセスを停止するためにシグナル制御を学ぼう!
yamamotohiroya
0
1.7k
カンファレンスはフィードバックが大事
yamamotohiroya
1
140
ISUCONのススメ
yamamotohiroya
0
920
Other Decks in Technology
See All in Technology
知識を整理して未来を作る 〜SKDとAI協業への助走〜
yosh1995
0
140
新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜
kameitomohiro
0
370
強化されたAmazon Location Serviceによる新機能と開発者体験
dayjournal
2
150
キャディでのApache Iceberg, Trino採用事例 -Apache Iceberg and Trino Usecase in CADDi--
caddi_eng
0
170
第9回情シス転職ミートアップ_テックタッチ株式会社
forester3003
0
130
Кто отправит outbox? Валентин Удальцов, автор канала Пых
lamodatech
0
270
OAuth/OpenID Connectで実現するMCPのセキュアなアクセス管理
kuralab
5
850
2025/6/21 日本学術会議公開シンポジウム発表資料
keisuke198619
2
470
本部長の代わりに提案書レビュー! KDDI営業が毎日使うAIエージェント「A-BOSS」開発秘話
minorun365
PRO
14
2.3k
AI技術トレンド勉強会 #1MCPの基礎と実務での応用
nisei_k
1
240
LinkX_GitHubを基点にした_AI時代のプロジェクトマネジメント.pdf
iotcomjpadmin
0
160
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
2
1.6k
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
462
33k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
4 Signs Your Business is Dying
shpigford
184
22k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
RailsConf 2023
tenderlove
30
1.1k
Docker and Python
trallard
44
3.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Faster Mobile Websites
deanohume
307
31k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Six Lessons from altMBA
skipperchong
28
3.8k
Statistics for Hackers
jakevdp
799
220k
GraphQLとの向き合い方2022年版
quramy
46
14k
Transcript
AUTO_INCREMENTのIDカラムが オーバーフローしたらどうなるの? 〜実例から学ぶ DB設計の注意点〜 NE株式会社 やまもとひろや PHPerKaigi2025 登壇資料
自己紹介 • やまもとひろや • NE株式会社 開発部マネージャー • X: @HiroyaYamamoto1 •
Qiita: @yamamoto_hiroya • Zenn: yamamoto_hiroya • 今回NE株式会社は4名登壇! • 新卒採用もやってるので是非! ◦ https://ne-inc.jp/recruit ◦ 「NE株 採用」で検索!
突然ですが 2147483647 これ何の数字か分かりますか?
そうですね! INT型の最大値ですね! (2^31-1)
4294967295 は分かりますか?
そうですね! 符号なし(UNSIGNED) INT型の最大値ですね!
今回は実際に UNSIGNED INTのIDカラムが 上限を超えた 弊社事例を紹介します!
目次 • INT型(UNSIGNED INT)とは • 実際に起きた弊社事例 • 対応方法と学び • まとめ
• 今回はMySQLのINT型に絞ってお話しします。 参照: https://dev.mysql.com/doc/refman/8.0/en/integer-types.html INT型(UNSIGNED INT)とは
INT型(UNSIGNED INT)とは 普通のINT (符号あり) UNSIGNED INT (符号なし) • 数値を入れるためのデータ型です。 •
赤い部分がそれぞれの範囲です。 • 通常のINTがマイナス値入るの忘れがち。 • UNSIGNEDはマイナス値入らない=符号なしとも呼ぶ • 自分用: INTは約21億、符号なしは約43億 0 -2147483647 4294967295 2147483647
実際に弊社で起きた事例 調査担当 私 以下エラーが出ているんですがどういう状況 か分かります? Duplicate entry '4294967295' for
key 'sample_table.PRIMARY'
ふむふむ どうやらsample_tableのPRIMARYの カラム(ID)が4294967295を書き込もうとし てエラーになっているみたいだね。 Duplicateなので既にそのID値は存在して いるみたい。 実際に弊社で起きた事例 調査担当 私
実際に弊社で起きた事例 調査担当 私 じゃあIDが4294967295のレコードが 悪さをしてそうだから 調査してレコード削除等をすれば いいですかね?
ん〜というか 4294967295はUNSIGNED INTの最大値 だから これもしかしてレコード上限 来ちゃってるかもね 実際に弊社で起きた事例 調査担当 私
実際に弊社で起きた事例 調査担当 私 え? UNSIGNED INTがオーバーフローすると Duplicateエラーになるんですか?
実際に弊社で起きた事例 • ある日突然以下のエラーが発生しました。 • Duplicate entry '4294967295' for key
'sample_table.PRIMARY' • データの書き込みが全て止まった。
再現テスト • 状況をローカル環境にて再現しました。 • テーブル定義は以下のものを使います。 • データは以下のようにします。
• この状態で新規レコードを追加しようとするとDuplicateエラーが再現し ました。 再現テスト
• 以下のような挙動をします。 • ID値が4294967295になった。 • 次の処理でAUTO_INCREMENTのためIDを+1しようとしたが最大値のた め4294967295のままになった。 • IDのカラムはPRIMARYのため重複できない。 •
そのため4294967295を再びINSERTしようとしてDuplicateエラーとなっ た。 • 補足: 現在のauto_increment値の 確認方法 • SHOW TABLE STATUS LIKE 'sample_table'; 解説
調査担当 私 レコードの削除をしてauto_incrementの値 をリセットする? どう対処したか 約43億のレコード削除はだいぶ時間がかか るので今回は難しそう。
調査担当 私 INT型を変えて桁数増やす? どう対処したか ALTERにだいぶ時間がかかるので今回は難 しそう。
調査担当 私 今のsample_tableをsample_table_oldと し、新しくsample_tableを作成する? どう対処したか RENAMEも新しいsample_table作成もサ クッとできる。作ったらすぐそのテーブルにレ コードが書き込まれ始める。 よし、これで行こう!
解決!
補足 • ちなみに今回の例はサービス開始し約5年で発生しました。 ◦ 1日235万レコードペース • そもそもそんな大量のデータをデータベースに持ちたいか?という観点か ら注意が必要です。 • どうしても持つ場合はBIGINTで持つと2^63乗まで持てます(約900京)
◦ 例えばこれを10年で使い切るには1日250兆のレコードが入り続ける必要があり、ほぼ使 い切らないくらい大きい上限値だと思ってもらって良いと思います。 ◦ もしBIGINTを使い切ったよっていうご経験がある方がいたら是非教えてください。
学び • AUTO_INCREMENTで • PRIMARYの • INT型の • ID値が •
上限に行くと • Duplicateエラーとなる。
まとめ • 安易なID値設計は辞めましょう。 ◦ デフォルトのINT型AUTO_INCREMENT, PRIMARYで本当に大丈夫か? • そもそもそのIDカラムは必要か? ◦ サロゲートキーか?ナチュラルキーか?
• 全て考えてIDカラムを持つとして、ものすごいレコードが入る場合は BIGINTにしましょう。 • そのテーブルは • 「どういう使われ方をするのか」 • 「どういうデータが入るのか」 • 「どれくらいの頻度で入るのか」 • これらを考えて適切なテーブル設計をしていきましょう!
None