SQLiteにおけるUUID型主キーのパフォーマンス上の落とし穴
本記事は、データベース設計においてランダムなUUID（Universally Unique Identifier）をプライマリキーとして使用することに伴う性能上の問題点について詳細に解説しています。特にSQLiteという環境に焦点を当てています。
まず、通常の`INTEGER PRIMARY KEY`（rowidを使用）を用いた場合のベンチマークが提示されました。1億行のデータ挿入にかかる時間は約715ミリ秒であり、これは非常に効率的です。これに対し、UUID4をプライマリキーとし、かつ`WITHOUT ROWID`オプションを使用したケースでは、同じ1億行の挿入に12,586ミリ秒という極端に長い時間（ベースラインと比較して14〜16倍遅い）がかかることが判明しました。この大幅な性能低下は、UUID4が持つ「順序性のなさ」が原因で、B-tree構造（クラスター化インデックス）の再バランス処理をSQLiteに頻繁に強いるためです。
さらに、時間順序性を考慮したUUID7を使用した場合のベンチマークも行われました。この場合、1億行の挿入時間は約12,586ミリ秒となり、前述のUUID4よりも改善が見られましたが、依然としてベースライン（INTEGER型）よりは遅い結果となりました。
また、`WITH ROWID`オプションを維持しつつUUID4を使用した場合も試されましたが、この場合もランダムな挿入によるインデックス構築の負荷から、性能面で優位性を示すことはできませんでした。結論として、SQLiteのような環境では、プライマリキーに順序性の高い整数型（INTEGER）を用いることが、データベースの書き込みパフォーマンスを最大化するための最善策であることが示されています。
背景
本記事は、リレーショナルデータベース管理システム（RDBMS）、特にSQLiteにおけるデータ構造とインデックス設計に関する高度な技術的考察に基づいています。UUIDのようなランダムIDを主キーに使う際、データの物理的な格納順序が崩れ、パフォーマンスが著しく低下するという問題点を検証しています。
重要用語解説
- クラスター化インデックス: テーブルの行データを物理的に特定の順序で格納する仕組みです。これによりデータアクセス効率が高まりますが、挿入時に順序を保つためのオーバーヘッドが発生します。
- rowid: SQLiteが標準で持つ暗黙的な64ビット整数型のプライマリキーであり、テーブルのデータがこのID順に物理的に格納されることを保証し、クラスター化インデックスとして機能します。
- UUID4: ランダムな値に基づいて生成される128ビットの識別子（Universally Unique Identifier）の一種です。高い衝突耐性を持つ反面、時間的な順序性がなく、データベースの挿入効率を低下させる原因となります。
今後の影響
この知見は、大規模なデータセットを扱うアプリケーション開発者にとって極めて重要です。単にユニークであることだけを目的としたUUIDの使用は避け、パフォーマンスが求められる場面では、時間ベースや連番など順序性を考慮したID設計を採用することが推奨されます。