【要約】【MySQL】「UUIDv7にすると速くなる」は本当。でも条件付きでテーブルサイズが大きくなる ~ InnoDB 1000万行を29回実測 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
RDBMSの設計において、主キーの選択は性能を左右する。開発者はUUIDv4かUUIDv7か、数値的根拠のないまま判断を迫られている。
- ・UUIDv4は挿入先が分散し、ページ分割コストと書き込み量が増大する。
- ・UUIDv7は高速化が期待されるが、実装次第でストレージ効率が劣化する。
- ・「UUIDv7は速い」という言説に対し、具体的な条件が不明確である。
// Approach
筆者はMySQL 8.4.11を用い、1000万行の書き込み実験で4つの主キー戦略を比較した。
- ・比較対象：UUIDv4、UUIDv7（ms内ランダム）、UUIDv7（ms内単調）、AutoIncrement。
- ・測定項目：挿入スループット、テーブルサイズ、ページ分割回数、書き込み量、フィルファクタ。
- ・環境制御：バッファプール内、単一ライタ、固定レコードサイズでの厳密な比較。
- ・検証内容：ミリ秒あたりの行数を変化させ、方向検出の限界を探索した。
// Result
実験の結果、UUIDv7はUUIDv4に対し、挿入速度を2.6〜3.3倍向上させた。
- ・書き込み効率：1ページあたりの書き込み回数がv4の15.8回に対し、v7系は1回前後。
- ・ストレージ効率：ミリ秒内が単調なv7は最小だが、ランダムな実装はv4よりサイズが増大する。
- ・結論：書き込み性能向上にはUUIDv7が有効だが、空間効率にはミリ秒内の単調性が必須である。
Senior Engineer Insight
> 書き込み性能とIOPSの観点から、UUIDv7への移行は極めて合理的だ。特にクラウド環境でのI/Oコスト削減に直結する。ただし、ストレージ容量重視なら、ライブラリの「ミリ秒内単調性」を検証せよ。また、自前実装時は4096行/msのオーバーフロー対策が必須である。安易な置き換えは、予期せぬストレージ増大を招くリスクがある。