データベースにおける UUID と auto-increment ID の比較

UUID と auto-increment ID の選択は、データベースの好みだけの問題ではありません。公開 URL、データインポート、シャーディング、インデックスの局所性、開発者がレコードをデバッグする方法にも影響します。

どちらも有効な選択です。より良い方は、識別子がどこを通るかで決まります。

auto-increment ID はシンプルでコンパクト

連番 ID は読みやすく、インデックスも効率的で、社内システムでは扱いやすいです。

• 42 は入力しやすい
• データベースインデックスがコンパクトに保たれる
• 新しい行は通常、互いに近い位置に入る
• ID でソートすると、多くの場合作成順に近づく

単一データベースで社内アプリを動かすなら、auto-increment ID で十分なことが多いです。

UUID は分散生成に向いている

レコードが中央の 1 つのデータベース外で作られる可能性があるとき、UUID が活きます。

• オフラインクライアントが同期前に ID を生成できる
• 複数サービスが独立して ID を生成できる
• インポート時に衝突を避けやすい
• 公開 URL から行数が推測されにくい
• イベントがシステム間で安定した ID を持てる

fixture、API 例、マイグレーションスクリプト用のテスト値が必要なら、UUID Generator が便利です。

公開 ID と内部 ID は分けられる

多くのシステムは両方を使います。

• データベースの join 用に内部の数値 primary key
• URL や API 参照用に公開 UUID または slug

こうすれば、データベース操作はシンプルなまま、予測可能な公開識別子を避けられます。

インデックスのトレードオフ

ランダムな UUID は、新しい値が自然にクラスタリングされないため、インデックスの局所性を下げることがあります。書き込みが非常に多いテーブルでは、これが問題になることがあります。

選択肢には次のようなものがあります。

• UUID を公開 ID にしつつ、内部では数値 primary key を使う
• 分散 ID とインデックス局所性の両方が必要なら、時系列 ID 形式を使う
• テーブルが高負荷の書き込みでなければ、最適化前に計測する

デバッグのトレードオフ

連番 ID はチャットやログで言いやすいです。UUID は打ち間違えにくい一方、目視で追いにくいです。

運用ツールでは、ID をコピーしやすく、検索しやすく、ラベルも明確にしてください。識別子戦略が、不必要にサポート作業を難しくしてはいけません。

実用的な判断基準

データが社内向けで集中管理され、パフォーマンスに敏感なら auto-increment ID を使います。ID がサービス境界をまたぐ、公開 URL に現れる、またはデータベース到達前に生成される必要があるなら UUID を使います。

両方の要件がある場合は、意図的に両方を使います。