データベースの主キーにUUID v4を使うと重い？衝突のリスクとパフォーマンスへの影響を徹底解説

データベース設計において主キーに何を採用するかは、システム全体の性能と将来のスケーラビリティに直結する重要な判断です。
近年では分散システムやマイクロサービスの普及に伴い、UUID v4を主キーとして採用するケースが増えています。
しかし一方で、「UUID v4は重いのではないか」「インデックス性能が劣化するのではないか」といった懸念も根強く存在します。

本記事では、UUID v4の基本特性を踏まえた上で、主キーとして利用した際の衝突リスクの現実的な評価と、データベース性能への影響について論理的に整理していきます。
特にB-treeインデックスにおける挿入特性やキャッシュ効率、さらにはストレージ断片化の観点から、実務上どのようなトレードオフが発生するのかを具体的に解説します。

また、UUID v4の利点と課題を比較しながら、用途によっては代替となる設計指針についても触れます。
例えば以下のような観点は設計判断において重要になります。

分散環境における一意性の担保と衝突確率の実態
ランダム性によるインデックスの局所性低下
シーケンシャルIDと比較した書き込み性能の違い

単に「UUIDは重い」という直感的な評価ではなく、データ構造とアルゴリズムの観点からその理由を分解し、実務での適用可否を判断できるようになることを目的としています。
データベース設計の意思決定に迷っている方にとって、具体的な指針となる内容を提供します。

データベース主キーにUUID v4を採用する基本と設計思想
UUID v4の生成方式とランダム性の仕組み
主キー設計とB-treeインデックスへの影響
UUID v4の衝突確率は本当に問題になるのか
UUID主キーによるデータベース性能劣化と書き込みコスト
自動採番IDとの比較でわかるUUIDのメリットとデメリット
クラウド環境（AWS RDSなど）でのUUID採用パターン
UUID v4運用のベストプラクティスと設計最適化手法
まとめ：UUID v4は本当に重いのかを正しく判断する

データベース主キーにUUID v4を採用する基本と設計思想

データベース設計において主キーは、レコードを一意に識別するための最も重要な要素です。
従来はオートインクリメント整数が主流でしたが、分散システムやマイクロサービスの普及により、UUID v4を主キーとして採用する設計が現実的な選択肢として広く検討されるようになっています。

UUID v4は、128ビットの値をランダム生成する方式であり、理論上ほぼ衝突しない一意性を持ちます。
この特性により、複数のサービスやデータベースが独立してIDを生成しても、後から統合する際にキーの衝突を気にする必要がほとんどありません。
特に以下のようなシステムでは有効です。

複数リージョンにまたがる分散システム
オフラインでIDを生成する必要があるモバイルアプリ
マイクロサービス間で疎結合を保ちたい設計

このような背景から、UUID v4は単なるID生成方式ではなく、「システムの独立性を高めるための設計思想」として捉える必要があります。

一方で、UUID v4の導入は単純な置き換えでは済みません。
データベース内部のインデックス構造やストレージ特性に影響を与えるため、設計レベルでの理解が不可欠です。
特にB-treeインデックスにおいては、ランダム性の高いキーが挿入順序を乱し、ページ分割や断片化を引き起こす可能性があります。

例えば、従来のシーケンシャルIDでは以下のような挿入順序になります。

1, 2, 3, 4, 5, ...

しかしUUID v4では完全にランダムなため、

c2a1..., 91f3..., a84b..., 0d91...

のように物理的な局所性が失われます。
この違いは単なる見た目の問題ではなく、キャッシュ効率やディスクI/Oにも影響を及ぼします。

また設計思想として重要なのは、「UUID v4は人間の可読性を犠牲にしてスケーラビリティを得るトレードオフ」であるという点です。
整数IDのように順序が直感的に分かるわけではなく、デバッグやログ追跡の際には追加の工夫が必要になります。

このため実務では、単純に主キーとしてUUID v4を採用するのではなく、以下のような補助設計を併用するケースが多く見られます。

外部公開用IDとしてUUID v4を使用し、内部処理は整数IDを維持
ULIDなど時間順ソート可能なIDへの置き換え検討
検索用途とは別にサロゲートキーを設計

つまりUUID v4の採用は、単なる技術選定ではなく「システムの拡張性と整合性をどこまで優先するか」という設計判断そのものになります。
データベースの物理構造とアプリケーションアーキテクチャの両面から理解することが重要です。

UUID v4の生成方式とランダム性の仕組み

UUID v4は、128ビットの識別子をランダム値ベースで生成する方式であり、その設計の本質は「統計的に衝突しにくい一意性」にあります。
アルゴリズム的には、暗号学的に安全な疑似乱数生成器（CSPRNG）を用いてビット列を生成し、その一部をバージョン情報とバリアント情報に割り当てることでフォーマットを満たします。

UUIDの構造を分解すると、単純なランダム値ではなく、仕様上の制約が組み込まれています。

122ビットがランダム値
4ビットがバージョン識別（v4の場合は0100）
2〜3ビットがバリアント識別

この設計により、見た目は完全にランダムでありながら、UUIDとしての互換性と標準化が保証されています。

ランダム性の源泉となるCSPRNGは、通常OSレベルで提供されるエントロピーソースに依存します。
Linuxであれば /dev/urandom、WindowsであればCryptGenRandomやBCryptGenRandomといったAPIが利用されます。
これにより、単純な疑似乱数（線形合同法など）とは異なり、予測困難性が担保されます。

ここで重要なのは、UUID v4の品質は「乱数生成器の品質」に強く依存するという点です。
つまりアルゴリズム自体は単純でも、実装環境のエントロピー供給が不十分であれば、理論上の衝突確率よりも現実的なリスクが上昇します。

衝突確率は誤解されやすいポイントですが、理論的には以下のようなビット空間を持ちます。

項目	ビット数	意味
ランダム部	122bit	一意性の源泉
バージョン	4bit	UUID v4識別
バリアント	2〜3bit	フォーマット識別

122ビットという空間は非常に広く、誕生日問題を考慮しても現実的なシステム規模では衝突はほぼ無視できるレベルです。
ただし「ほぼゼロ」と「絶対ゼロ」は数学的に異なるため、金融システムや分散トランザクションでは設計上のレビュー対象になることがあります。

また実装上の注意点として、乱数生成のタイミングや並列生成の仕方によっては、微妙な偏りが生じるケースも存在します。
特に以下のような環境では注意が必要です。

コンテナ起動直後でエントロピーが不足している場合
組み込み環境など乱数源が限定されている場合
独自実装のUUID生成ロジックを使用している場合

このようなリスクを回避するため、現代のフレームワークやデータベースドライバでは、標準ライブラリのUUID生成関数を使用することが強く推奨されています。

結果としてUUID v4は「単なるランダムID」ではなく、「エントロピー品質に依存する分散識別子」として理解するのが正確です。
この理解を持つことで、後述する衝突リスク評価やパフォーマンス影響の議論もより現実的なものになります。

主キー設計とB-treeインデックスへの影響

データベースにおける主キー設計は、単なる一意性の確保にとどまらず、物理的なストレージ構造や検索性能に直接影響を与える重要な設計要素です。
特に多くのRDBMSで採用されているB-treeインデックス構造においては、キーの性質がパフォーマンス特性を大きく左右します。

B-treeは階層構造を持つバランス木であり、各ノードがキーの範囲を管理することで対数時間での検索・挿入・削除を実現しています。
しかし、この構造は「キーがある程度順序性を持つ場合」に最も効率的に動作します。
例えば、整数型のオートインクリメントIDは単調増加するため、常に右端への追加挿入となり、ページ分割が最小限に抑えられます。

一方でUUID v4のように完全にランダムなキーを主キーとして使用した場合、この前提が崩れます。
挿入は木構造のあらゆる位置に分散するため、以下のような影響が発生します。

リーフノードの分割頻度が増加する
ディスク上のページ局所性が低下する
キャッシュヒット率が低下する
フラグメンテーションが進行しやすくなる

このような現象は、理論的な計算量ではO(log n)で変わらないものの、実際のI/O性能やCPUキャッシュ効率に強く影響します。

特にストレージレベルでは、連続書き込みとランダム書き込みの差が顕著になります。
HDD環境ではシーク時間の増加、SSD環境でも書き込み増幅やガベージコレクションの負荷増大といった形で現れます。

比較を整理すると、主キーの性質によるB-tree挙動の違いは以下のようになります。

項目	シーケンシャルID	UUID v4
挿入位置	常に末尾	ランダム
ページ分割	低頻度	高頻度
キャッシュ効率	高い	低下しやすい
フラグメンテーション	少ない	増加しやすい

この違いは特に書き込み中心のワークロードにおいて顕著です。
例えばログデータやイベントストリームのような大量挿入が発生するシステムでは、UUID v4のランダム性がボトルネックになるケースがあります。

ただし重要なのは、UUID v4が常に劣っているわけではないという点です。
読み取り主体のシステムや、分散環境でのデータ統合が重要な場合には、B-treeのローカル最適化よりも一意性と独立性が優先されます。

また近年では、この問題に対する解決策として、時系列性を持つID設計も普及しています。
例えばULIDやKSUIDのような方式では、先頭にタイムスタンプを含めることでインデックスの局所性を改善しつつ、UUID的な一意性を維持します。

結果として、主キー設計とB-treeの関係は単純な性能比較ではなく、「データの書き込みパターンとスケーラビリティ要件のトレードオフ」として評価する必要があります。
設計者はシステムの負荷特性を正しく把握した上で、適切なID戦略を選択することが求められます。

UUID v4の衝突確率は本当に問題になるのか

UUID v4を主キーとして採用する際に最も頻繁に議論される論点の一つが「衝突確率」です。
理論上、UUID v4は122ビットのランダム空間を持ち、その組み合わせ数は約5.3×10^36通りに達します。
この巨大な空間により、現実的なシステム規模では衝突はほぼ起こらないとされています。

しかし重要なのは、「ほぼ起こらない」と「絶対に起こらない」は異なるという点です。
データベース設計においては、この微小な確率をどのように扱うかが設計判断になります。

衝突確率を直感的に理解するためには、誕生日問題の考え方が有効です。
N個のUUIDを生成した場合の衝突確率は、理論的には以下のように近似されます。

P ≈ 1 - exp(-N² / (2 × 2^122))

この式から分かる通り、Nが現実的な範囲であればPは極めて小さな値になります。
例えば10億件（10^9）のUUIDを生成した場合でも、衝突確率は実質的にゼロに近い値です。

ただし、この理論値は「理想的な乱数生成器」を前提としています。
実際のシステムでは以下のような要因が影響します。

エントロピー不足による乱数品質の低下
仮想環境やコンテナ初期化直後の偏り
不適切な独自実装UUID生成ロジック

これらの要因が重なると、理論上の衝突確率よりも実際のリスクは高くなります。
特にクラウド環境で大量のインスタンスが同時に起動するようなケースでは、乱数シードの初期化状態が問題になることがあります。

また、システム設計上の誤りとして見落とされがちなのが「衝突検知の欠如」です。
UUIDは統計的にユニークであることを前提としているため、通常は衝突チェックを厳密に行いません。
しかし金融システムや決済処理などでは、理論上ゼロに近い確率であっても整合性検証が必要になる場合があります。

衝突リスクの評価を整理すると、以下のようになります。

観点	内容	実務影響
理論確率	極めて低い	無視可能
実装依存	乱数品質に依存	条件次第で変動
システム規模	大規模でも安全域	通常問題なし
設計要件	厳格な検証が必要な場合あり	一部業務で重要

重要なのは、UUID v4の衝突リスクは「数学的リスク」ではなく「実装と運用リスク」として評価すべきだという点です。
多くのシステムでは理論的安全性が十分に高いため問題になりませんが、ゼロリスクを要求する領域では追加の検証層が必要になります。

さらに現代の分散システムでは、UUIDの衝突よりも「データ整合性の破綻」や「レプリケーション遅延」の方がはるかに現実的な問題です。
そのため、UUID v4の衝突確率を過度に恐れることは設計の優先順位を誤らせる可能性があります。

結論として、UUID v4の衝突確率は理論的には無視できるレベルであり、多くのユースケースでは実務上の問題にはなりません。
ただし、その安全性は「正しい乱数生成と適切な実装」に依存しているため、完全なブラックボックスとして扱うのではなく、前提条件を理解した上で採用することが重要です。

UUID主キーによるデータベース性能劣化と書き込みコスト

UUIDを主キーとして採用する際に最も現場で問題になりやすいのが、書き込み性能の劣化です。
特に高頻度でINSERTが発生するシステムでは、UUID v4のランダム性がデータベース内部の物理構造に影響を与え、結果として書き込みコストが増大します。

この問題の本質は、データベースのインデックス構造とストレージの特性にあります。
多くのRDBMSはB-treeインデックスを使用しており、キーの順序性が高いほど効率的に動作します。
しかしUUID v4は完全にランダムな値であるため、挿入位置が常に分散し、既存ノードの再配置が頻繁に発生します。

その結果として以下のような負荷が増加します。

ページ分割（page split）の頻発
インデックス再バランス処理の増加
ディスクI/Oのランダムアクセス化
バッファキャッシュの局所性低下

これらは単体では小さなコストに見えますが、高トラフィック環境では累積的に大きな差となって現れます。
特に秒間数千〜数万INSERTが発生するようなシステムでは、書き込み性能のボトルネックとして顕在化しやすくなります。

実際の挙動を理解するために、シーケンシャルIDとUUID v4の書き込み特性を比較すると次のようになります。

項目	シーケンシャルID	UUID v4
挿入位置	常に末尾	ランダム位置
ページ分割頻度	低い	高い
インデックス局所性	高い	低い
書き込みI/O	連続的	分散的
キャッシュ効率	良好	劣化しやすい

この差は、特にストレージがSSDであっても完全には吸収されません。
SSDはランダムアクセスに強いとはいえ、書き込み増幅（write amplification）やガベージコレクションの負荷は避けられないため、UUID v4のランダム書き込みは依然としてコストになります。

さらに重要なのは、インデックスサイズの増加によるメモリ効率の低下です。
UUIDは128ビット（16バイト）であり、一般的なINT型（4バイト）と比較して4倍のサイズを持ちます。
この差は単純なストレージ消費だけでなく、B-treeノードの分岐数にも影響します。

ノード内に格納できるキー数が減ることで、ツリーの深さが増加し、結果として検索および更新のパスも長くなります。
これにより、CPUキャッシュミス率が上昇し、レイテンシにも影響が出ます。

また、実務上見落とされがちな点として「書き込み増加によるバックアップコスト」もあります。
インデックスが肥大化することで、スナップショット生成やレプリケーション転送量も増加し、インフラ全体のコストに波及します。

ただし重要なのは、UUID v4が常に非効率というわけではないという点です。
以下のような条件では、性能劣化の影響は相対的に小さくなります。

読み取り主体のワークロード
書き込み頻度が低いマスターデータ
分散環境でのID生成の独立性が優先される設計

つまりUUID v4の性能問題は「絶対的な欠点」ではなく、「ワークロード依存のトレードオフ」です。
システム設計においては、単純なベンチマークではなく、実際のアクセスパターンを基に評価する必要があります。

結論として、UUID主キーは書き込みコストの観点で明確な不利を持つものの、それを上回る設計上のメリット（分散性・独立性・統合容易性）が存在する場合には合理的な選択肢となります。
重要なのは性能劣化の存在そのものではなく、それを許容できるアーキテクチャかどうかの判断です。

自動採番IDとの比較でわかるUUIDのメリットとデメリット

データベース設計において主キーの選択は、単なる技術的選好ではなく、システム全体のアーキテクチャに影響する重要な意思決定です。
特に従来から広く利用されている自動採番ID（オートインクリメント整数）と、UUID v4のような分散型識別子を比較すると、その性質の違いは明確に浮かび上がります。

自動採番IDは、基本的にデータベース側が連番で整数値を割り当てる仕組みです。
この方式の最大の利点は、順序性とコンパクトさにあります。
例えばINSERT時には常に末尾に追加されるため、B-treeインデックスにおけるページ分割が最小限に抑えられ、書き込み性能が安定しやすくなります。
また、4バイト程度の整数で表現できるため、ストレージ効率やキャッシュ効率の面でも優れています。

一方で、この方式には明確な制約も存在します。
特に分散環境においては、複数ノードで同時にIDを生成できないため、中央集権的なID発行機構が必要になります。
これはスケーラビリティや可用性の観点でボトルネックとなり得ます。

これに対してUUID v4は、各ノードが独立してIDを生成できるため、分散システムとの親和性が非常に高いという特徴を持ちます。
ネットワーク越しの調整なしに一意なIDを生成できるため、マイクロサービスやクラウドネイティブなアーキテクチャでは大きな利点となります。

両者の違いを整理すると、以下のようになります。

項目	自動採番ID	UUID v4
一意性生成	DB依存	分散生成可能
サイズ	小（4バイト）	大（16バイト）
インデックス効率	高い	低下しやすい
スケーラビリティ	制約あり	高い
順序性	あり	なし

この比較から分かる通り、自動採番IDは「性能と効率」を重視した設計であり、UUID v4は「分散性と独立性」を重視した設計です。

実務上の重要なポイントは、どちらが優れているかではなく、「システム要件に対してどちらが適合するか」という判断になります。
例えば単一データベースで完結する業務システムであれば、自動採番IDの方が明らかに合理的です。
一方で、複数リージョンやサービス間連携が前提となるシステムでは、UUID v4の方が設計上の摩擦を減らすことができます。

また、運用面の違いも無視できません。
自動採番IDは予測可能であるため、セキュリティ上のリスク（ID列挙攻撃など）が発生する可能性があります。
一方UUIDは予測困難であるため、この種の攻撃に対しては自然な耐性を持ちます。

ただしUUIDにもデメリットは明確に存在します。
可読性の低さやデバッグの難しさ、さらにインデックス肥大化による性能劣化は、実運用で頻繁に問題となります。
そのため実務では、以下のようなハイブリッド構成が採用されることも多いです。

内部主キーは自動採番ID
外部公開用IDとしてUUIDを付与
APIやURLではUUIDを利用

このような設計により、両者の利点をバランス良く取り入れることが可能になります。

結論として、自動採番IDとUUID v4は競合する技術ではなく、それぞれ異なる設計思想に基づくツールです。
重要なのは性能・スケーラビリティ・運用性のどれを優先するかを明確にし、それに応じて適切な主キー戦略を選択することです。

クラウド環境（AWS RDSなど）でのUUID採用パターン

クラウド環境におけるデータベース設計では、オンプレミスとは異なる制約と最適化ポイントが存在します。
特にAWS RDSやCloud SQLのようなマネージドデータベースサービスでは、スケーラビリティや可用性を前提とした設計が求められるため、UUID v4の採用が現実的な選択肢として頻繁に登場します。

クラウド環境でUUIDが好まれる最大の理由は、「分散性」と「独立性」です。
マイクロサービスアーキテクチャでは、複数のサービスがそれぞれ独立してデータを生成・保存するため、中央でIDを採番する方式はボトルネックになりやすい構造を持ちます。
その点UUID v4は各サービスがローカルでIDを生成できるため、サービス間の依存関係を最小化できます。

例えばAWS環境では以下のような構成でUUIDが利用されることが多く見られます。

Amazon RDS（PostgreSQL / MySQL）での主キーとしてUUIDを採用
DynamoDBのパーティションキーとしてUUIDを利用
Lambda関数間のイベントIDとしてUUIDを付与

このように、UUIDは単なるデータベースキーではなく、システム全体の識別子として扱われる傾向があります。

一方でクラウド環境特有の課題として、UUID v4のインデックス性能問題がより顕在化するケースもあります。
RDSのようなマネージドサービスではストレージの内部構造を完全に制御できないため、B-treeインデックスの断片化やキャッシュ効率低下を直接チューニングすることが難しい場合があります。

そのため実務では、UUID採用時に以下のような設計パターンがよく用いられます。

プライマリキーはUUID、検索用に別インデックスを設計
作成日時（created_at）とUUIDを組み合わせた複合インデックス
ソート用途にはULIDなど時系列性のあるIDを併用

特にULIDのような時間順ソート可能なIDは、クラウド環境でのUUID代替として注目されています。
これはUUIDの分散性を維持しながら、インデックス局所性の問題を部分的に解決するアプローチです。

クラウド環境におけるID設計の比較を整理すると次のようになります。

方式	分散適性	インデックス効率	運用性	主な用途
UUID v4	非常に高い	低下しやすい	高い	マイクロサービス全般
自動採番	低い	高い	中	単一DBシステム
ULID	高い	中程度	高い	時系列データ
Snowflake系	高い	高い	中	大規模分散システム

このようにクラウド環境では、単純な性能比較ではなく「運用とスケール戦略」がID選定に強く影響します。

またAWS RDSなどの環境では、リードレプリカやマルチAZ構成が一般的であり、データ同期の観点からもUUIDの独立性は有利に働きます。
各ノードが独立して書き込みを行う場合でもID衝突を気にする必要がないため、アーキテクチャの自由度が高まります。

ただし注意すべき点として、UUIDの肥大化によるコスト増加があります。
ストレージ使用量の増加だけでなく、ネットワーク転送量やバックアップ時間にも影響するため、大規模データベースでは無視できない要素になります。

結果としてクラウド環境におけるUUID採用は、「スケーラビリティを優先する設計判断」であると同時に、「運用コストと性能劣化を許容するトレードオフ」でもあります。
したがって採用可否は単なる技術選定ではなく、システム全体の成長戦略に依存する設計判断となります。

UUID v4運用のベストプラクティスと設計最適化手法

UUID v4を実務で運用する際には、単に主キーとして採用するだけでは不十分であり、データベース設計・アプリケーション設計・運用設計の三層で最適化を行う必要があります。
特にUUID v4はランダム性による柔軟性と引き換えに、インデックス効率やストレージ効率に影響を与えるため、設計段階での工夫が重要になります。

まず基本的なベストプラクティスとして重要なのは、「UUIDの役割を明確に分離すること」です。
すべての用途にUUID v4を使うのではなく、用途ごとにIDの性質を分けることで、性能と運用性のバランスを取ることができます。

代表的な設計パターンは以下の通りです。

主キーにはUUID v4を使用し、外部公開APIでも同一IDを利用
内部処理やソート用途には別途シーケンシャルIDを併用
ログやイベントIDには軽量なID生成方式を採用

このように責務を分離することで、UUIDの「分散性」という利点を活かしながら、インデックス負荷を局所的に抑えることができます。

次に重要なのが、インデックス設計の最適化です。
UUID v4はランダム性が高いため単一インデックスでは性能劣化が起こりやすく、複合インデックスの設計が有効になります。
例えば以下のような構成が一般的です。

sql CREATE INDEX idx_user_created_at ON users (created_at, id);sql

このように時系列カラムとUUIDを組み合わせることで、実質的なソート効率を補うことができます。
特に「created_at + UUID」の組み合わせは、ページ分割の偏りを緩和する効果があります。

またストレージレベルでの最適化も重要です。
UUIDは16バイトと比較的大きいため、インデックス肥大化が避けられません。
そのため以下のような工夫が推奨されます。

最適化手法	内容	効果
バイナリ保存	CHAR(36)ではなくBINARY(16)を使用	ストレージ削減
圧縮インデックス	InnoDB圧縮などを利用	I/O削減
キャッシュ調整	バッファプール拡張	読み取り高速化

特にMySQLやPostgreSQLでは、UUIDを文字列として保存するよりもバイナリ形式で保存する方が明確に効率が良くなります。
これはインデックスノード内の収容効率に直接影響するため、実務上は必須の最適化といえます。

さらにアプリケーション層では、UUID生成の一貫性も重要です。
言語ごとに異なる実装を混在させると、フォーマット差異やバージョン違いによる不整合が発生する可能性があります。
そのため標準ライブラリを統一的に使用し、独自実装を避けることが推奨されます。

運用面では、UUID採用時に以下のような観点も考慮する必要があります。

ログ解析時の可読性低下への対策
デバッグ時のトレーサビリティ確保
分散トレーシングとの統合

特にマイクロサービス環境では、UUIDをトレースIDとして活用することで、サービス間のリクエスト追跡が容易になります。
この場合、UUIDは単なる主キーではなく「観測可能性（observability）」の基盤として機能します。

また近年では、ULIDやKSUIDのような代替IDの採用も増えています。
これらはUUIDのランダム性を保ちながら時間順ソート性を持つため、インデックス効率の改善に寄与します。
ただし完全なUUID互換ではないため、既存システムとの整合性には注意が必要です。

結論として、UUID v4の運用最適化は単一の技術改善ではなく、「データベース設計・インデックス設計・アプリケーション設計・運用設計」の総合的な調整問題です。
適切な設計を行えばUUIDの柔軟性を損なうことなく、性能面の課題を十分に制御することが可能になります。

まとめ：UUID v4は本当に重いのかを正しく判断する

UUID v4は「重い」「遅い」といった評価を受けることが多いですが、その評価は単一の性能指標だけを切り取った場合の誤解であることが少なくありません。
実際には、UUID v4の特性はデータベース内部構造・アーキテクチャ設計・運用要件との相互作用によって決まるため、文脈依存で評価すべき技術です。

まず整理すべき重要な点は、UUID v4の本質が「ランダム性による分散適性」にあるということです。
この特性は以下のような環境で大きな価値を持ちます。

マイクロサービスなど複数システムが独立してIDを生成する場合
マルチリージョン構成でデータを統合する必要がある場合
オフライン環境やクライアントサイドでIDを生成する場合

これらのケースでは、中央集権的なID採番よりもUUID v4の分散生成能力の方が設計上の利点になります。

一方で、性能面の課題は確かに存在します。
特にB-treeインデックスとの相性により、以下のような影響が発生します。

インデックスのページ分割頻度の増加
キャッシュ局所性の低下
書き込みI/Oのランダム化
ストレージ肥大化によるメモリ効率低下

これらは理論的な問題ではなく、実際の高負荷システムで観測される実務的な課題です。
ただし重要なのは、これらの影響が「常に致命的になるわけではない」という点です。

例えば読み取り中心のシステムや、書き込み頻度が比較的低いマスターデータ管理では、UUID v4の性能ペナルティは無視できる範囲に収まることが多くなります。
またSSDや大容量キャッシュを持つクラウド環境では、物理的な影響が相対的に緩和されるケースもあります。

ここで重要になるのは「何と比較して重いのか」という視点です。
自動採番IDと比較すれば確かにUUID v4はコストが高いですが、それは「ローカル最適化された設計」との比較です。
一方で分散性やスケーラビリティを考慮した場合、そのコストは合理的なトレードオフになります。

判断基準を整理すると、UUID v4の採用可否は次のように分解できます。

観点	UUID v4が適する場合	UUID v4が不利な場合
スケール	分散・マルチリージョン	単一DB構成
書き込み負荷	低〜中程度	高頻度INSERT
運用要件	独立性重視	厳密な性能最適化
データ構造	疎結合アーキテクチャ	密結合・高速処理