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
570
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
7.1k
プルリクサイズが大きいと警告してくれる君を作りました!
yamamotohiroya
1
450
安全にプロセスを停止するためにシグナル制御を学ぼう!
yamamotohiroya
0
1.8k
カンファレンスはフィードバックが大事
yamamotohiroya
1
140
ISUCONのススメ
yamamotohiroya
0
930
Other Decks in Technology
See All in Technology
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
6
330
AI工学特論: MLOps・継続的評価
asei
10
2k
マルチモーダル基盤モデルに基づく動画と音の解析技術
lycorptech_jp
PRO
2
270
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
880
The Madness of Multiple Gemini CLIs Developing Simultaneously with Jujutsu
gunta
1
2.8k
MCPと認可まわりの話 / mcp_and_authorization
convto
2
300
[TechNight #91] Oracle Database 最新パフォーマンス分析手法
oracle4engineer
PRO
3
170
DatabricksのOLTPデータベース『Lakebase』に詳しくなろう!
inoutk
0
160
激動の時代、新卒エンジニアはAIツールにどう向き合うか。 [LayerX Bet AI Day Countdown LT Day1 ツールの選択]
tak848
0
610
AI によるドキュメント処理を加速するためのOCR 結果の永続化と再利用戦略
tomoaki25
0
110
ビジネス文書に特化した基盤モデル開発 / SaaSxML_Session_2
sansan_randd
0
150
機械学習を「社会実装」するということ 2025年夏版 / Social Implementation of Machine Learning July 2025 Version
moepy_stats
1
1.4k
Featured
See All Featured
Balancing Empowerment & Direction
lara
1
510
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Scaling GitHub
holman
461
140k
How STYLIGHT went responsive
nonsquared
100
5.7k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
How to Ace a Technical Interview
jacobian
278
23k
The Language of Interfaces
destraynor
158
25k
The World Runs on Bad Software
bkeepers
PRO
70
11k
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