(jp) =
Spatie では、多くのデータベース テーブルで UUID を使用する大規模なプロジェクトに取り組んでいます。 これらのテーブルのサイズは、数千レコードから 50 万レコードまでさまざまです。
ご存じかもしれませんが、通常の UUID は次のように保存されます。 CHAR(36) データベースのフィールド。 MySQL はこれらのレコードを適切にインデックス化できないため、これには膨大なパフォーマンス コストがかかります。 次のグラフを見てください。100 クエリの実行時間を 2 つのデータセット (50k 行のデータセットと 500k 行のデータセット) に対してプロットしています。
テキスト UUID を使用すると、平均 1.5 秒以上かかります。
ある 重要な編集 ここ: 上記のベンチマークは、インデックスのないフィールドで実行されました。 それ以来、より公正な比較のために、ベンチマーク結果をインデックス付きテキスト フィールドで動作するように変更しました。 テキスト UUID を使用しないことによるパフォーマンスの向上はまだあるので、読み続けてください。
より良い代替案を探したところ、2 つの部分からなる解決策が見つかりました。
# UUID をバイナリデータとして保存
UUID を CHAR、実際のバイナリ データを BINARY 分野。 それらをこの形式で保存すると、MySQL はこのテーブルのインデックス作成の問題を大幅に軽減できます。 これは、はるかに高速な結果をプロットしたグラフです。
これは、クエリあたりの平均が 0.00008832061291 秒であるのに対し、 索引付き テキスト UUID。
#もっと上手になる！
UUID のバイナリ エンコーディングにより、ほとんどの問題が解決されました。 ただし、追加の手順が 1 つあります。これにより、MySQL は大規模なデータセットに対してこのフィールドのインデックスをさらに適切に作成できます。
UUID の一部のビット、より具体的には時間関連のデータを切り替えることで、より順序付けられた方法でそれらを保存できます。 また、MySQL は、インデックスを作成するときに順序付けられたデータを特に好むようです。 注意すべき重要な点が 1 つあります。今回の関連ビットは、UUID バージョン 1 でのみ使用できます。
このアプローチを使用すると、次の結果が得られます。
最適化されたアプローチは、小さなテーブルでのルックアップでは実際には遅くなりますが、大規模なデータセットでは通常のバイナリ アプローチよりも優れています。 よりも優れたパフォーマンスを発揮します。 AUTO_INCREMENT 整数 ID! しかし、ご覧のとおり、最適化された UUID の利点を得るには、非常に大きなテーブルが必要です。
非常に優れたユースケースがある場合にのみ、UUID を使用することをお勧めします。 例: 1 つのテーブルだけでなく、すべてのテーブルで一意の ID が必要な場合。 または、テーブルにある行数を正確に隠したい場合。
MySQL チームは、この UUID のビットシフトについて詳しく説明したブログ投稿を書きました。 内部でどのように機能するかを知りたい場合は、まずこちらから始めてください。
Laravel アプリケーションを構築していて、プロジェクトで最適化された UUID を使用したい場合は、特別にパッケージを作成しました。 ベンチマークの詳細については、こちらの README にも記載されています。
最後に、Laravel 以外のプロジェクトでこの動作を実装することを検討している場合は、Ramsey の UUID パッケージを確認する必要があります。私たちもそれを使用しています!