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
660
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.6k
プルリクサイズが大きいと警告してくれる君を作りました!
yamamotohiroya
1
480
安全にプロセスを停止するためにシグナル制御を学ぼう!
yamamotohiroya
0
1.9k
カンファレンスはフィードバックが大事
yamamotohiroya
1
140
ISUCONのススメ
yamamotohiroya
0
930
Other Decks in Technology
See All in Technology
GraphRAG グラフDBを使ったLLM生成(自作漫画DBを用いた具体例を用いて)
seaturt1e
1
150
DSPy入門
tomehirata
3
370
知覚とデザイン
rinchoku
1
610
ストレージエンジニアの仕事と、近年の計算機について / 第58回 情報科学若手の会
pfn
PRO
3
870
QA業務を変える(!?)AIを併用した不具合分析の実践
ma2ri
0
160
SOTA競争から人間を超える画像認識へ
shinya7y
0
600
Azure Well-Architected Framework入門
tomokusaba
1
140
Zero Trust DNS でより安全なインターネット アクセス
murachiakira
0
110
SCONE - 動画配信の帯域を最適化する新プロトコル
kazuho
1
400
What's new in OpenShift 4.20
redhatlivestreaming
0
320
Okta Identity Governanceで実現する最小権限の原則 / Implementing the Principle of Least Privilege with Okta Identity Governance
tatsumin39
0
180
AI時代の発信活動 ~技術者として認知してもらうための発信法~ / 20251028 Masaki Okuda
shift_evolve
PRO
1
110
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.7k
The Invisible Side of Design
smashingmag
302
51k
The World Runs on Bad Software
bkeepers
PRO
72
11k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
How STYLIGHT went responsive
nonsquared
100
5.9k
Code Reviewing Like a Champion
maltzj
526
40k
Keith and Marios Guide to Fast Websites
keithpitt
411
23k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
A designer walks into a library…
pauljervisheath
209
24k
Scaling GitHub
holman
463
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
Music & Morning Musume
bryan
46
6.9k
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