大量の挿入には MySQL の主キーとして UUID を使用する必要がありますか?

MySQL の UUID パフォーマンス: 考慮事項と推奨事項

毎秒 100 ～ 40,000 件の範囲の挿入の主キーとして UUID を考慮している MySQL ユーザーは、パフォーマンスに関する懸念。

ストレージ形式:

当初は UUID を VARCHAR(36) として保存することが検討されていますが、BINARY(16) の方が効率的であり、ストレージ領域が大幅に削減されます。

インデックスに対するランダム データの影響:

ランダムに分散された UUID は、特に大規模なインデックスのパフォーマンスに悪影響を及ぼす可能性があります。データセット (5,000 万レコード以上)。連続した順序が欠けていると、ページが断片化され、選択のパフォーマンスが低下します。

UUID タイプとタイムスタンプ付きの値:

タイムスタンプ付きの左端ビットを持つタイプ 1 UUID は、パフォーマンスを向上させる可能性があります。固有の順序により、ページの断片化が軽減されます。ただし、正確なタイムスタンプを保証するには、慎重な実装が必要です。

代替としての主キーの自動インクリメント:

主キーの自動インクリメントにより、シーケンシャルな順序が提供され、挿入パフォーマンスが最大化されます。そして断片化を軽減します。さらに、自動増分は本質的に小さくなり、ストレージのオーバーヘッドが削減されます。

推奨事項:

前述の要件と潜在的なパフォーマンスの課題に基づいて、推奨されるアプローチは使用しないことです。主キーとしての UUID。代わりに、次のハイブリッド モデルを検討してください。

1. 挿入パフォーマンスを最適化するために主キーとして INT Identity 列を使用します。
2. 複数のデータベースにわたるデータ整合性のために追加の UUID 列を自動的に生成します。

以上が大量の挿入には MySQL の主キーとして UUID を使用する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。